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

RESOLVED WORKSFORME

Status

RESOLVED WORKSFORME
14 years ago
10 years ago

People

(Reporter: steffen.wilberg, Assigned: blizzard)

Tracking

({qawanted, regression, testcase})

Trunk
x86
Linux
qawanted, regression, testcase
Bug Flags:
blocking1.8b3 -
blocking1.8b5 -

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

14 years ago
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.
(Reporter)

Comment 1

14 years ago
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>&nbsp;</td>
</table>

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

Updated

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

Comment 3

14 years ago
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.
Keywords: regression
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+

Comment 6

14 years ago
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
Flags: blocking1.8b3?

Updated

14 years ago
Flags: blocking1.8b4?
Flags: blocking1.8b3?
Flags: blocking1.8b3-
Keywords: qawanted
Whiteboard: GTK2+xft only

Updated

14 years ago
Whiteboard: GTK2+xft only → [no l10n impact] 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. ***

Comment 9

14 years ago
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. 

Updated

14 years ago
QA Contact: ian → gtk
(Assignee)

Comment 10

14 years ago
I can reproduce on gtk2/xft but not gtk2/pango.

Comment 11

14 years ago
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.

Comment 13

14 years ago
>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

14 years ago
(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

14 years ago
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.

Updated

14 years ago
Attachment #191473 - Attachment mime type: text/x-log → text/plain

Comment 16

14 years ago
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

14 years ago
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.

Updated

14 years ago
Flags: blocking1.8b4? → blocking1.8b4-

Comment 20

13 years ago
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

13 years ago
Workaround:

set browser.display.focus_ring_width to 0.
*** Bug 324148 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

13 years ago
Summary: Blocks jump when clicking on links → Blocks jump when clicking on links (GTK2+xft only)
Whiteboard: [no l10n impact] GTK2+xft only

Comment 23

13 years ago
(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

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

NO, this is used by accessibility
(Reporter)

Comment 25

12 years ago
WFM now on current Linux trunk.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.