130023 - Make the URL in the "you are missing MathML fonts"-dialog text a working link

Status: RESOLVED WONTFIX

(Core :: MathML, enhancement)

Description

[Roland Mainz]

RFE: There is an URL in the "you are missing MathML fonts"-dialog - it should be
a working link...

Comment 1

[rbs]

-> re-assigning to XP - GUI features because the RFE is a general bug that
affects all alert windows. The GUI support doesn't provide provisions to fix it
from the MathML side.

A screenshot of the MathML dialog was made in bug 128139
http://bugzilla.mozilla.org/attachment.cgi?id=71830&action=view

The RFE is to enable <a href="...">...</a> to be supported in the text of such
dialogs.

Comment 2

[Roland Mainz]

rbs:
Can we simply use a HTML link from the XHTML namespace in the XUL code ?

Comment 3

[rbs]

That wouldn't work ATM. You can try it by editing the current text in
mathfont.properties. If you add <a href="...">...</a>, it gets rendered
verbatim. That's what I was saying in bug 125541 comment #30. The reason is
because the text in the alert message isn't parsed/added as a document fragment
with possibly nested nodes. If you have a chance to lookup the JS code that I
indicated, you will see more clearly what is happening.

Comment 4

[Paul Wyskoczka]

--> QA [e-mail]

Comment 5

[rbs]

The code that handles the text is:
http://lxr.mozilla.org/seamonkey/source/xpfe/global/resources/content/commonDial
og.js#88

If XUL documents were already supporting |createContextualFragment|, the code
could perhaps be replaced with something such as:

+   var range = document.createRange();
+   range.setStartAfter(parentNode);
+   var innerMarkup = range.createContextualFragment(messageParagraphs[i]);
+   parentNode.appendChild(innerMarkup);

Comment 6

[rbs]

I tried the following patch but it crashed on me because
nsRange::CreateContextualFragment() seems to bend too much towards HTML (e.g., 
it creates a HTML content sink rather than a sink based on the current 
document's content-type). See also bug 133827 (and to some extend bug 5222 about 
XUL's createDocumentFragment)

Index: commonDialog.js
===================================================================
RCS file: /cvsroot/mozilla/xpfe/global/resources/content/commonDialog.js,v
retrieving revision 1.46
diff -u -r1.46 commonDialog.js
--- commonDialog.js     9 Feb 2002 03:36:55 -0000       1.46
+++ commonDialog.js     21 Apr 2002 18:48:09 -0000
@@ -91,9 +91,10 @@
   var messageParagraphs = messageText.split("\n");

   for (var i = 0; i < messageParagraphs.length; i++) {
-    var descriptionNode = document.createElement("description");
-    var text = document.createTextNode(messageParagraphs[i]);
-    descriptionNode.appendChild(text);
+    var range = document.createRange();
+    range.setStart(messageParent, i);
+    var descriptionNode = range.createContextualFragment(
+      '<description>' + messageParagraphs[i] + '</description>');
     messageParent.appendChild(descriptionNode);
   }

Comment 7

[Roland Mainz]

The same functionaliy is now needed for the print error dialog.

Does anyone have an idea who can take that bug and fix it somehow for the
mozilla-1.4 series?

Comment 8

[rbs]

A clean fix for this bug is going to follow from bug 133827 which needs to be
fixed first.

Comment 9

[rbs]

Another independent fix could be to just re-design the dialog with a provision
for a link, like for example in Prefences -> Appearances - Themes -> Get New Themes.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Is this dialog modal?  Because you most certainly cannot have a usable link in 
a modal dialog.... (think app-modal modality).

Wouldn't it make more sense to have a "Go Get Fonts" button instead?

Comment 11

[rbs]

The MathML one is non-modal (non-blocking). But the printer one is modal (as
yet).

"Go Get Fonts" or "More About MathML Fonts" or something like that are OK, so
long as it is clickable.
screenshot: http://bugzilla.mozilla.org/attachment.cgi?id=71830

The full URL was given as a way to tell people to type it, but not surprizingly,
users want convenience...

Comment 12

[rbs]

Attachment: patch

Comment 13

[timeless]

inline style is evil, what if as a user i set links to be pink? or what if my
theme wants them to be beige?

Comment 14

[rbs]

Attachment: screenshot showing the dialog with clickable lick

Comment 15

[rbs]

I concur with comment 13. Is there a XUL .link class somewhere that can be
re-used here?

Comment 16

[Boris Zbarsky [:bzbarsky]]

class="text-link" should do the job, last I checked.

Comment 17

[rbs]

Attachment: patch - next iteration

Still iterating. In this one, I had to explicitly include formatting.css to get
the .text-link class to work. Why is that so? Am I missing something?

Comment 18

[rbs]

Attachment: testcase for .text-link - use View -> Use Style to toggle formatting.css

A testcase to see for yourself that formatting.css is needed explicitly. It
seems strange. If you toggle off its inclusion, the link styles disappear.

Comment 19

[Boris Zbarsky [:bzbarsky]]

formatting.css is not included by any of the "general" theme files.

I'm not sure whether it should be....

Comment 20

[rbs]

> formatting.css is not included by any of the "general" theme files.

What about this query of LXR (at least on Win32 and the Mac): 
http://lxr.mozilla.org/mozilla/search?string=formatting.css

/themes/classic/global/mac/global.css, line 45 -- @import
url("chrome://global/skin/formatting.css");

/themes/classic/global/unix/global.css, line 45 -- @import
url("chrome://global/skin/formatting.css");

/themes/classic/global/win/global.css, line 45 -- @import
url("chrome://global/skin/formatting.css");

/themes/modern/communicator/communicator.css, line 46 -- @import
url("chrome://communicator/skin/formatting.css");

Comment 21

[Boris Zbarsky [:bzbarsky]]

Hmmm... you're right; if global.css is included, formatting.css should be
included by it..

Comment 22

[[e-mail]]

Because the text-link class is, at least in the Suite, in communicator's
formatting.css, not in the global formatting.css ...

pref-themes.xul seems to get away with an <html:a target="_blank">, but I
wouldn't know if you can use it when creating a contextual fragment. It's also
possible that there are existing alert strings containing malformed XML.

Note that window.open will inherit modality from the dialog; we had the same
issue trying to open help from various dialogs.

Comment 23

[Jesse Ruderman]

*** Bug 307696 has been marked as a duplicate of this bug. ***

Comment 24

[rbs]

*** Bug 309178 has been marked as a duplicate of this bug. ***

Comment 25

[Serge Gautherie (:sgautherie)]

rbs,
Are you still working on this ?

Comment 26

[Frédéric Wang Nélar]

Attachment: Make the URL a working link

Comment 27

[Karl Tomlinson (:karlt)]

ALERT_MISSING_FONTS is currently not defined.  For reasoning see here:
http://hg.mozilla.org/mozilla-central/annotate/7c7654971790/layout/mathml/nsMathMLChar.cpp#l818

Comment 28

[Frédéric Wang Nélar]

(In reply to comment #27)
> ALERT_MISSING_FONTS is currently not defined.  For reasoning see here:
> http://hg.mozilla.org/mozilla-central/annotate/7c7654971790/layout/mathml/nsMathMLChar.cpp#l818

Yes, I saw this comment. Do you mean a fix for this bug should also include a "don't tell me again box" and move the checking of fonts inside Stretch? BTW, is there something that currently prevents to easily do this move?

Comment 29

[Frédéric Wang Nélar]

Attachment: Screenshot of the dialog

Comment 30

[Frédéric Wang Nélar]

Attachment: Add a dialog "Link + Checkbox"

It seems a bit difficult to add the "don't tell me again" feature: on the one hand you want to use a nonblocking alert in nsMathMLChar.cpp but on the other hand you need to wait the final state of the checkbox...

Comment 31

[Karl Tomlinson (:karlt)]

(In reply to comment #28)
> Do you mean a fix for this bug should also include a
> "don't tell me again box" and move the checking of fonts inside Stretch? BTW,
> is there something that currently prevents to easily do this move?

I don't think I've seen a bug report requesting that this dialog be
resurrected.

If we do restore something, then it should be a notification rather
than a dialog (bug 309090), and the notification should only appear if there
is good reason to think that installing additional fonts will make the page
render better.

I think it could be quite difficult to detect whether installing additional
fonts will help.  Stretch would be the place to try to work that out but it
may not be easy.

Modern operating systems have reasonably good font support, so effort would
probably be better spent making good use of the fonts that are likely to be
installed.

For example, bug 414277 would mean that grouping symbols could be the correct
size even of systems without special parts of such symbols (even though they
wouldn't be as pretty as glyphs designed for that size), and this would
improve some situations even with STIX fonts because some grouping symbols
cannot be constructed from parts horizontally or vertically.

Also, fixing bug 403958 would mean that radical symbols could be built from
parts from Cambria Math (bug 372351) and/or (I think) OpenSymbol (from
OpenOffice, no bug filed yet).