269643 - When clicking link, page redraws with different layout, click is ignored

Status: RESOLVED FIXED

(Core :: Layout: Tables, defect)

Description

[Jim Booth]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8a5) Gecko/20041112
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.8a5) Gecko/20041112

When I click on a link, the browser redraws the screen and the link moves down,
but does not go to the link destination.  Have to click the link again. 

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.mysql.com
2. Click on any link on main top menu bar, such as "Products"

Or, second example
1. Go to http://www.bankofamerica.com
2. Enter anything in the Online ID and Passcode fields
3. Click the Sign On button
Actual Results:  
The browser redraws the page, shifting the link down a line, instead of going to
the linked page. 

On www.mysql.com, the menu strip shifts down a bit, leaving a white stripe above
it. 

On www.bankofamerica.com, the line "View demo | Learn more | Enroll" rewraps
with "Enroll" on the next line, moving the button down. 

In either case, clicking the link again goes to the proper page. 

Expected Results:  
Go to the page for that link.

Sorry if this is a dupe, but I have searched and not found it.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> 1. Go to http://www.mysql.com

Bug 262576

> 1. Go to http://www.bankofamerica.com

Don't see a bug for this one; minimal testcase needed (please do not file layout
bugs as NEW without one).

Comment 2

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 3

[Vincent Lefevre]

Same problem (using the testcase) under Linux/PPC, using Mozilla (CVS checkout
and compiled a few hours ago). Hardware/OS should be set to All/All.

Comment 4

[Caleb]

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

Using the testcase, and focusing the "Sign In" link does not do a thing, yet
actually clicking on it re-arranges the table.

Comment 5

[Bernd]

the typical maximumWidth issue see bug 147558 for guidance how to debug such a
problem

Comment 6

[Jim Booth]

I notice that the testcase has only one cell in the second row, while rows 1 and
3 have colspan=2, but adding a second cell in row 2 does not solve the problem.  

Comment 7

[Peter Weilbacher]

As remarked before, this is All/All, here it happens with

Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8b4) Gecko/20050726 SeaMonkey/1.0a

Comment 8

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

bernd, are you going to be able to work on this?

Comment 9

[Bernd]

thats clearly a table issue

    cell 04025EC8 d=2205,330 me=450 m=450
   row 04025E6C d=2205,330
  rowG 040DE6B0 d=2205,1350
 tbl 04025714 d=2265,1410 me=510 m=465 <<<<<<
tblO 04025608 d=2265,1410 me=510 m=465

the maximumWidth is based only on the last reflown table cell but not on all
columns it should be 2205 and not 465.

Comment 10

[Bernd]

The bug is inside BasicTableLayoutStrategy::ComputeNonPctColspanWidths during
initial layout the DES_ADJ colframe width is wrong.

The algorithm sees how much space is available to distribute, and then tries to
assign the remainder to the DES_ADJ, where it fails as there is already a larger
DES width. The widths are not cumulative so it should not try to assign the
reminder but the whole width which should be lower bounded by the PCT & Fix width.

I need to think about this algorithm a little bit more.

Comment 11

[Bernd]

Attachment: patch

The issue here is that the desired content width is used to compute the
maximumWidth. So if we dont assign to pct and fixed width columns the
corresponding DES_ADJ width we will end with a too small maximumWidth. During
the initial reflow this is not a problem as we reflow unconstrained and the pct
column is treated as autowidth column so we assign the necessary DES_ADJ. But
during incr. reflow there is a constrained width so the pct column has a real
value and we substract that pct width and assume that we need only to
distribute the remaining des width but this is IMHO wrong.

This things needs to be rtest'ed  before review

Comment 12

[Peter Weilbacher]

Comment on attachment 191890 [details] [diff] [review]
patch

Not sure what testing you had in mind but I have been running SeaMonkey with
this patch for the past week and not noticed anything bad. (I also didn't
notice any changes for the better other than the testcase in this bug.)

Comment 13

[Martijn Wargers (dead)]

Probably he meant this:
http://www.mozilla.org/newlayout/doc/regression_tests.html

Comment 14

[Bernd]

Attachment: testcase that fails with attachment 191890

Comment 15

[Bernd]

I think this should not block rc1. There are three reasons:
- I rather work on crash bugs till the release, like bug 311661
- I have no good idea how to fix this.
- My time is very limited, and I am not aware of anybody other than Chris
Karnaze and me who knows the colspan balancing code good enough to work out a
proper fix.

Comment 16

[Scott MacGregor]

This is not a stop ship bug for 1.5

Comment 17

[Robert Glover]

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

Comment 18

[Daniel Schroeter]

Cause in den Weblogs of Asa someone said "It [this bug] will probably be fixed in time for the next major release after 1.5." I would like to nominate this bug for 1.8.1 because this bug still annoying me the most time I use FF under Linux.

Comment 19

[Bernd]

for me this bug goes after reflow refactor.

Comment 20

[Darin Fisher]

Not going to block 1.8.1 for this bug, but we'll happily consider a baked-on-trunk patch.

Comment 21

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20061208 Minefield/3.0a1 ID:2006120812 [cairo]

seems fixed by reflow branch landing

Comment 22

[Martijn Wargers (dead)]

Yeah, it's still a problem with a 2006-12-06 build, but it is fixed on the 2006-12-08 build -> fixed by the reflow branch.

Comment 23

[Ryan VanderMeulen [:RyanVM]]

Adding in-testsuite? nomination per bz's request in m.d.t.l. Sorry for the bugspam.

Comment 24

[Konstantin Boyandin]

Attachment: Test case to show the bug still exists in Firefox 2.0.0.5

This file demonstrates that the bug still exists in Firefox 2.0.0.5

Comment 25

[Martijn Wargers (dead)]

Yes, it wasn't fixed on the branch (which is where Firefox2 comes from), it was fixed on trunk.
If you want to test this, then you should test trunk:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/