Hyperlink annotations regression

[GitHubRulesOK]

Keeping this as a separate issue from other hyperlink regressions as seems to be a different cause
From Forum https://forum.sumatrapdfreader.org/t/links-inside-a-pdf-not-working/3783
UNE-EN_1991.pdf

Page 15 has a standard "GoTo" page link to 49 which works, however on page 49 there are stamped ? arrows that seem to be annotation links back to the source page thus the first "return" (volver) arrow should link back to page 15.

This works most (but not all) times whilst viewing in a browser , and Did work in SumatraPDF Version 3.1.2 but not in 3.2 or latest. (they do not work in MuPDF 1.18)

[kjk]

In 3.1.2 in pdf_load_link there is no check for Subtype so it accepts Widget as link, in addition to Link

In 3.2 pdf_load_link only accepts Link but the links on page 49 are Widget.

I've opened mupdf bug: https://bugs.ghostscript.com/show_bug.cgi?id=703834

This would fix it:

diff --git a/mupdf/source/pdf/pdf-link.c b/mupdf/source/pdf/pdf-link.c
index 5ccefcf1a..8de33b464 100644
--- a/mupdf/source/pdf/pdf-link.c
+++ b/mupdf/source/pdf/pdf-link.c
@@ -405,7 +405,7 @@ pdf_load_link(fz_context *ctx, pdf_document *doc, pdf_obj *dict, int pagenum, fz
        fz_link *link = NULL;

        obj = pdf_dict_get(ctx, dict, PDF_NAME(Subtype));
-       if (!pdf_name_eq(ctx, obj, PDF_NAME(Link)))
+       if (!(pdf_name_eq(ctx, obj, PDF_NAME(Link)) || pdf_name_eq(ctx, obj, PDF_NAME(Widget))))
                return NULL;

        obj = pdf_dict_get(ctx, dict, PDF_NAME(Rect));

[kjk]

mupdf closed this as wontfix with this explanation:

Those are buttons, not links :)

Older versions of MuPDF didn't handle buttons, so we converted simple buttons with follow-a-link actions into links. We can't do that anymore without risking breaking interactive documents using javascript actions in forms and widgets.

I guess this means this should be handled as a button in JavaScript

[GitHubRulesOK]

Since I agree SumatraPDF should not currently be using Scripting as exploitable I am closing as cant fix historic code unless write custom script follower.

[GitHubRulesOK]

mupdf closed this as wontfix with this explanation:

Those are buttons, not links :)

Older versions of MuPDF didn't handle buttons, so we converted simple buttons with follow-a-link actions into links. We can't do that anymore without risking breaking interactive documents using javascript actions in forms and widgets.

I guess this means this should be handled as a button in JavaScript

I am not so certain that JS or ecma script is required as they are visually more like /Action script variant of goto

339 0 obj
<</A 381 0 R/AP<</D 385 0 R/N 386 0 R>>/H/P/MK<</I 382 0 R/IF<</FB true>>/TP 1>>/P 133 0 R/Parent 345 0 R/Rect[19.2366 521.185 45.0367 542.385]/Subtype/Widget/Type/Annot>>
endobj

seems to be related to MuPDF inaction on tooltips as seen in #2391 (comment)