Created attachment 530122 [details] Reduction of the bug. Using MathJax and a converter of mine, I've created some MathML that you find attached (the attachment is a reduced version of the complete output). Using Firefox 4.0.1, the "Subst.:" text is displayed left of the open brace/<mfenced>, whereas on Nightly (2011-05-03) the "Subst." starts together with the open brace which means it's misaligned. Removing the at the beginning of the <mtext> makes the text get displayed at the right position.
I haven't managed to reproduce on Linux or Win7. I've added qawanted because I don't have a Mac.
I've done a regression window serach by using the builds from http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/: WORKS 2011-04-18-03-mozilla-central-debug: 2e5e4197b9db FAILS 2011-04-19-03-mozilla-central-debug: 1c819504b0bb Hoping this helps to get this fixed.
Thanks, Julian. That should be helpful: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2e5e4197b9db&tochange=1c819504b0bb Nothing super obvious, though perhaps one of these: http://hg.mozilla.org/mozilla-central/rev/b895bc3e7a24 http://hg.mozilla.org/mozilla-central/rev/dc4b44f3e3f7 Does the bug continue to happen when zooming at various different sizes? What if you specify font-family on the math or mtext as something that doesn't result in Times New Roman getting selected?
Created attachment 536858 [details] Update reduction to include different font-family, font-size
@karlt: Upated the reduction and posted a screenshot. Changing the font-family to "Arial" fixes the bug. Changing the font-size doesn't.
I'm not seeing this bug on a 10.5 Mac. It looks like we both have 'Times' as the main font. The attachment is usually treated as UTF-8 here but, even when I choose ISO-8859-1, a different font is being used for the Euro and the spacing between the table rows is less here. The difference may be due to different fonts on the different systems. I made a couple of builds for narrowing the regression range further: https://email@example.com/try-macosx64/firefox-6.0a1.en-US.mac.dmg is based on 0e8c23e50c6c. If that is not showing the bug, then please test https://firstname.lastname@example.org/try-macosx64/firefox-6.0a1.en-US.mac.dmg which is based on 2648367a59f0.
Thanks for working on this :) > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ > email@example.com/try-macosx64/firefox-6.0a1.en-US.mac.dmg > is based on 0e8c23e50c6c. Works as expected. Everything renders fine. > If that is not showing the bug, then please test > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ > firstname.lastname@example.org/try-macosx64/firefox-6.0a1.en-US.mac.dmg > which is based on 2648367a59f0. Fails - the bug looks the same as in the screenshot attached to this bug.
OK thanks. This looks like a regression triggered by bug 641426. Can you guess why you might be seeing something different to me? Which release of MacOS? Which fonts in this list do you have installed? http://hg.mozilla.org/mozilla-central/annotate/a52b04dc29ea/layout/mathml/mathml.css#l57 Do you still see the bug with a new profile? http://support.mozilla.com/en-US/kb/Managing-profiles#w_creating-a-profile
Here are some more builds for narrowing down the regression range http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e8c23e50c6c&tochange=2648367a59f0 to a particular patch: http://email@example.com/try-macosx64/firefox-6.0a1.en-US.mac.dmg is based on c3bf4b3ec506 If that fails (shows this bug) then please try http://firstname.lastname@example.org/try-macosx64/firefox-6.0a1.en-US.mac.dmg based on 12f37ad53b41 Otherwise (if the first build works as expected), please try http://email@example.com/try-macosx64/firefox-6.0a1.en-US.mac.dmg based on 8d64029c1725 (91e75937d34a doesn't build.)
(In reply to comment #9) > Can you guess why you might be seeing something different to me? Sorry, got no idea :( > Which release of MacOS? I'm running MacOsX 10.6.7. > Which fonts in this list do you have installed? > http://hg.mozilla.org/mozilla-central/annotate/a52b04dc29ea/layout/mathml/ > mathml.css#l57 The ones NOT installed are: DejaVu Serif DejaVu Sans Cambria Math OpenSymbol Standard Symbols L serif I determed "beeing" installed by opening the MacOsX "Font Book" application and searched for the font name. If it appeared, it is installed, otherwise it isn't. > Do you still see the bug with a new profile? > http://support.mozilla.com/en-US/kb/Managing-profiles#w_creating-a-profile Yes.
(In reply to comment #10) > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ktomlinson@mozilla. > com-fa35a3501cfa/try-macosx64/firefox-6.0a1.en-US.mac.dmg > is based on c3bf4b3ec506 Works. > Otherwise (if the first build works as expected), please try > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ktomlinson@mozilla. > com-48bd7d07a7f9/try-macosx64/firefox-6.0a1.en-US.mac.dmg > based on 8d64029c1725 Fails.
Can I ask you to edit the font-family, please, as you did with 'Arial', but start with "font-family: STIXGeneral, DejaVu Serif, DejaVu Sans, Cambria, Cambria Math, Times, Lucida Sans Unicode, OpenSymbol, Standard Symbols L, serif;" and reduce it to a minimal list of families still showing the bug? I assume you can at least remove the families that you don't have installed, but I expect it can be narrowed further.
There are some big changesets in the c3bf4b3ec506..8d64029c1725 range. These are builds for the remaining two changesets. They are debug builds to be smaller (no 64-bit version). They are in order so if the first fails, there is no need to try the second (or if the second works, there is no need to try the first). http://firstname.lastname@example.org/try-macosx-debug/firefox-6.0a1.en-US.mac.dmg is based on 964231489dde. http://email@example.com/try-macosx-debug/firefox-6.0a1.en-US.mac.dmg is based on 90e46b3e8e6f
(In reply to comment #14) > There are some big changesets in the c3bf4b3ec506..8d64029c1725 range. > These are builds for the remaining two changesets. They are debug builds to > be smaller (no 64-bit version). > They are in order so if the first fails, there is no need to try the second > (or if the second works, there is no need to try the first). > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ktomlinson@mozilla. > com-ade933f56c34/try-macosx-debug/firefox-6.0a1.en-US.mac.dmg > is based on 964231489dde. > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ktomlinson@mozilla. > com-2442d9a691da/try-macosx-debug/firefox-6.0a1.en-US.mac.dmg > is based on 90e46b3e8e6f Both builds work fine for me. Haven't done testing with the font-families as requested in comment #13. Will do that.
Thanks, Julian. That gets us down to something in these two changesets: http://hg.mozilla.org/mozilla-central/rev/91e75937d34a http://hg.mozilla.org/mozilla-central/rev/8d64029c1725
Created attachment 540217 [details] Reduction #3 Adds more font-family.
Testing the updated test caes and running the latest Nightly, only the font-family "STIXGeneral" fails. All other font-families render as expected.
91e75937d34a seems unlikely to be the cause. I see these changes in 8d64029c1725: ns(Int)Rect::UnionRect with two empty rects changed from doing Empty() to assigning aRect2. ns(Int)Rect::ScaleRoundOut changed from float to double precision. gfxRect::Intersect changed from returning empty rects as (0,0,0,0) to (maxX,maxY,0,0).
Testing this bug with the current version of nightly (8.0a1 (2011-08-06)), I can't reproduce this bug anymore. Changing the bug's status to RESOLVED/WORKSFORME (hope that's the right one).
WFM is right, thanks Julian.