Similar symptoms as bug 273392: Load the given url, click on one of the topics. Result: The link you clicked on gets wrapped to two lines.
Created attachment 182342 [details] testcase I added some stuff to make it validate as HTML 4.01 Strict. Sufficient to show the bug is this: <table> <td><a href="#">Click me!</a> </td> </table> If you click on the link, it gets wrapped to two lines.
WFM - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050430 Firefox/1.0+.
This works fine on Firefox 1.0.3, but is broken on trunk for quite some time. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+ I'm using GTK2.
Interesting. I can reproduce this in Firefox and in a Seamonkey GTK2/XFT build, but _not_ in a Seamonkey GTK1/no-XFT build. These last two builds are built from the same exact source tree, and the only other difference in confiugre options is in the optimization flags (and static vs. dynamic linking). So either XFT is returning inconsistent font measurement results, or it's returning something (probably not pixel-aligned?) that layout sort of fails to deal with.... Over to GTK GFX, since that's where XFT issues live, iirc.
Assignee: nobody → blizzard
Component: Layout → GFX: Gtk
QA Contact: layout → ian
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050501 Firefox/1.0+
WFM - Mozilla/5.0 (X11; U; Linux i686; de-AT; rv:1.8b2) Gecko/20050501 Note that this is a GTK2+Xft build here: --enable-cairo --enable-default-toolkit=gtk2 --enable-xft --disable-freetype2
Whiteboard: GTK2+xft only
*** Bug 301355 has been marked as a duplicate of this bug. ***
*** Bug 296809 has been marked as a duplicate of this bug. ***
can one of you who is seeing this problem narrow down the regression window by looking at builds from archive.mozilla.org? That would probably help a lot.
I can reproduce on gtk2/xft but not gtk2/pango.
When I reported Bug 296809, I wrote that this issue did not appear in 1.8b1. Looks like I was wrong, because I just tested some older builds: 1.8b1, 1.8a6 and 1.8a5 releases (gtk2+xft). And an archive build from: http://archive.mozilla.org/pub/mozilla/nightly/2004-08-05-23-trunk/ I can reproduce this bug in all of those four builds, always started with a clean user profile. Neither the gtk1 builds are affected, nor the gtk2+xft builds of the 1.7.x line.
I cannot reproduce this for the life of me, but one presumes it's a table issue.
>but one presumes it's a table issue as far as tables honor block information containing wrong MEW or maximumWidth sure, ;-), But I can't help here. I don't have linux build. If somebody sees this in a debug build please get a reflow log (http://www.mozilla.org/newlayout/doc/frame_reflow_debug.html) and attach it to the bug.
(In reply to comment #13) > ... If somebody sees > this in a debug build please get a reflow log > (http://www.mozilla.org/newlayout/doc/frame_reflow_debug.html) and attach it to > the bug. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050731 Firefox/1.0+ Possible relevant mozconfig lines: ac_add_options --enable-debug ac_add_options --disable-optimize ac_add_options --enable-default-toolkit=gtk2 ac_add_options --enable-xft I debugged with * 1 in GECKO_DISPLAY_REFLOW_RULES_FILE and I'll attach the relevant lines from a log of the results shortly. The log is of from my homemade Linux DEBUG build, using the testcase attached to this bug (attachment 182342 [details]). I do see the bug as described in comment 1.
Created attachment 191473 [details] DEBUG and REFLOW log Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050731 Firefox/1.0+ DEBUG + GECKO_DISPLAY_REFLOW (GECKO_DISPLAY_REFLOW_RULES = "* 1") Log for attachment 182342 [details]. The lines are numbered as they were in the original log, but I have removed sections that I assume weren't relevant (I have the full log if required.) The XXXdjc comments on the left inform of what is happening at each stage of the log. The log includes some basic information, then the log from the page loading, then a log of the page reflowing after clicking on the link.
Attachment #191473 - Attachment mime type: text/x-log → text/plain
I doubt that this is table issue at all, the log indicates more that the block inline frame interaction when one needs to compute the MEW is somehow strange. 4238 block 0x89797ac r=1 a=1065,UC c=1065,UC cnt=613 4239 inline 0x8979a28 r=1 incr. (Style) a=UC,UC c=UC,UC cnt=614 4240 text 0x897a490 r=3 a=UC,UC c=UC,UC cnt=615 4241 text 0x897a490 d=1005,255 me=555 4242 inline 0x8979a28 d=1005,255 me=555 4243 text 0x897a520 r=2 a=UC,UC c=UC,UC cnt=616 4244 text 0x897a520 d=60,255 me=60 4245 inline 0x8979a28 r=2 a=1065,UC c=UC,UC cnt=617 4246 text 0x897a490 r=2 a=1065,UC c=UC,UC cnt=618 4247 text 0x897a490 d=585,255 me=525 status=0x1 4248 inline 0x8979a28 d=585,255 me=525 status=0x1o=(0,0) 0 x 0sto=(-15,-15) 1035 x 285 4249 inline 0x8889a54 r=0 a=1065,UC c=UC,UC pif=0x8979a28 cnt=619 4250 text 0x897af38 r=0 a=1065,UC c=UC,UC pif=0x897a490 cnt=620 4251 text 0x897af38 d=420,255 me=555 4252 inline 0x8889a54 d=420,255 me=555 4253 text 0x897a520 r=2 a=645,UC c=UC,UC cnt=621 4254 text 0x897a520 d=60,255 me=60 4255 block 0x89797ac d=1065,510 me=555 m=1065 o=(-15,-15) 1080 x 540 When clicking a link this causes a incr. reflow due to the outliner. So the incr. reflow with type style change is targeted at the inline at line 4239. The block sees that a child is targeted and reflows it with an unconstrained width (a=UC, UC). At line 4242 it returns the same width as it did during the initial reflow. Then the nbsp is reflowed and returns the same 60 as during initial reflow. Up to this everything is in the green region. Then the block as it did reflow its children with an unconstrained width reflows it again with an constrained width. It reflows the inline with a larger available width than it desired, 1065 instead of 1005. Now the text inside the inline all over sudden decides that it does not fit into 1065 even if it reported during the unconstrained reflow only 1005 and requires a next in flow. The inline generates a new line, the text wraps, the block reports strange overflow values and so on. What is so special about this? During incr. reflow the table code requires both MEW and maximumWidth knowledge while reflowing the children with a constrained width. During the initial reflow it reflows the children with a unconstrained width and asks for MEW. It takes the reported desired width as the maximumWidth. As usual when somelines wrap one needs to look for the maximumWidth. In other words what does the textframe report at line 4241 one width but does not fit into it at line 4247?
s/what does/why does/
It sounds like some kind of font metrics problem. For the people who can reproduce this --- can you figure out exactly which font is being used, at which size?
Blizzard, I'm afraid that it might be up to you to debug this since you can reproduce it and you know the font code... Find me on IRC if you need help with the layout side.
This seems to be the same symptom as bug 279761, and testcase 2 of that bug seems to be identical to the one here. (Not sure if both share the same underlying problem, though. So I leave it so someone more knowlegeable to dupe one to the other.)
Workaround: set browser.display.focus_ring_width to 0.
*** Bug 324148 has been marked as a duplicate of this bug. ***
Summary: Blocks jump when clicking on links → Blocks jump when clicking on links (GTK2+xft only)
Whiteboard: [no l10n impact] GTK2+xft only
(In reply to comment #21) > Workaround: > > set browser.display.focus_ring_width to 0. Workaround works for me. No jumping links anymore. Can we make this setting default until the cause of this problem is evaluated and fixed?
> Can we make this setting default until the cause of this problem is evaluated and fixed? NO, this is used by accessibility
WFM now on current Linux trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.