292534 - Blocks jump when clicking on links (GTK2+xft only)

Status: RESOLVED WORKSFORME

(Core Graveyard :: GFX: Gtk, defect)

Description

[Steffen Wilberg]

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.

Comment 1

[Steffen Wilberg]

Attachment: 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>&nbsp;</td>
</table>

If you click on the link, it gets wrapped to two lines.

Comment 2

[Uri Bernstein]

WFM - Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2)
Gecko/20050430 Firefox/1.0+.

Comment 3

[Steffen Wilberg]

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.

Comment 4

[Boris Zbarsky [:bzbarsky]]

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.

Comment 5

[Steve England [:stevee]]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050501
Firefox/1.0+

Comment 6

[Robert Kaiser]

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

Comment 7

[Mats Palmgren (inactive)]

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

Comment 8

[Mats Palmgren (inactive)]

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

Comment 9

[Asa Dotzler [:asa]]

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. 

Comment 10

[Christopher Blizzard (:blizzard)]

I can reproduce on gtk2/xft but not gtk2/pango.

Comment 11

[big-jukka]

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.

Comment 12

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I cannot reproduce this for the life of me, but one presumes it's a table issue.

Comment 13

[Bernd]

>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.

Comment 14

[Daniel C]

(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.

Comment 15

[Daniel C]

Attachment: 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.

Comment 16

[Bernd]

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?

Comment 17

[Bernd]

s/what does/why does/

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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?

Comment 19

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 20

[Peter Weilbacher]

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.)

Comment 21

[sirius_b]

Workaround:

set browser.display.focus_ring_width to 0.

Comment 22

[Philip Withnall (unavailable)]

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

Comment 23

[big-jukka]

(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?

Comment 24

[Bernd]

> Can we make this setting default until the cause of this problem is evaluated and fixed?

NO, this is used by accessibility

Comment 25

[Steffen Wilberg]

WFM now on current Linux trunk.