395333 - [reflow branch] Password and Login box is displaced on accesd.desjardins.com

Status: RESOLVED WORKSFORME

(Tech Evangelism Graveyard :: French, defect)

Description

[Gabriel Chadwick]

On the desjardins.com (Bank) website the password and login text and box are displaced since recent nightly builds. See screenshots. Tested with Mozilla/5.0 (Windows; U; Windows NT 6.0; fr; rv:1.9a8pre) Gecko/2007090604 Minefield/3.0a8pre.

Comment 1

[Gabriel Chadwick]

Attachment: Incorect trunk rendering screenshot

Comment 2

[Gabriel Chadwick]

Attachment: Correct rendering

Comment 3

[:Gavin Sharp [email: [e-mail]]]

Can you find a regression range?

Comment 4

[Gabriel Chadwick]

It regressed before Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a8pre) Gecko/2007081505 Minefield/3.0a8pre. Sorry I don't know where to find earlier builds.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

You can find older builds at http://archive.mozilla.org/pub/firefox/nightly/ (takes a little while to load).

Comment 6

[Gabriel Chadwick]

The regression range is between the 20061207 and 20061208 builds. The 20061208 build is regressed. I tested monthly after that not one builds that I tested did it correctly. There where allot of checkins during that period and I have almost no knowledge of code so I can't help for this.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

That matches the landing period of bug 300030, which was a major reworking of the layout code. It's likely that this bug is a duplicate of one of the other bugs in bug 300030's dependency list.

Comment 8

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Looks like it may have something to do with an unsatisfied percentage width on a column-spanning cell, although it's hard to tell without fiddling with a testcase in older builds / other browsers.

Comment 9

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (minimized)

Here's a minimized testcase.  I don't think percentages come into play -- it's just how we balance column-spanning cells.

The underlying issue seems to be two rows like this, whose colspans both sum to 5, which we handle differently in trunk vs. branch:

  [colspan = 1][colspan=2][colspan=2]
  [  colspan = 2   ][ colspan  = 3  ]

The first row of that schematic represents the "Numero de carte" row on the original page. (Or it can represent the password row -- it doesn't matter, we only need one of those to reproduce the problem).  The second row represents the row with the lock and cell phone pictures at the bottom of the box on the original page.

In this minimized testcase, the orange box corresponds to the "Numero de Carte" text and textfield.  The blue div (with specified width) represents the lock image, which also has specified width.

Notice that the orange box starts further to the left on branch than it does on trunk.  (Screenshots coming.)That's the bug.

Comment 10

[Daniel Holbert [:dholbert]]

Attachment: screenshot (testcase 1, trunk)

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshot (testcase 1, branch)

Comment 12

[Boris Zbarsky [:bzbarsky]]

Daniel, what does IE's rendering of your testcase look like?

Comment 13

[Gabriel Chadwick]

Attachment: screenshot IE7 rendering

Screenshot of IE7 rendering looks almost the same as branch.

Comment 14

[Boris Zbarsky [:bzbarsky]]

So do we basically count the pref width of a colspan only against the first column it spans?  That's basically what things look like to me.  If I remove all the test in the testcase and just have some divs with widths to give the preferred widths in px as follows (and a total table width of 200px):

  [colspan = 1, pref=10][colspan=2, pref=10][colspan=2, pref=10]
  [  colspan = 2, pref=100 ][ colspan  = 3  ]

Then it looks like we calculate our total pref width as 120px, have 80 px to distribute, give 80*100/120 of it to column 1 and the divide the rest evenly between what looks like columns 3 and 5?  Or something like that; for sure the width of the colspan=3 ends up 24px, which means that it gets all the extra width that goes with those 20px pref width.

Interestingly, removing the 10px pref width on the colspan=1 does change the width we give to column 1.  Not quite sure why.

Comment 15

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #14)
> So do we basically count the pref width of a colspan only against the first
> column it spans?  That's basically what things look like to me.

No, we distributed it among the spanned columns in proportion to the intrinsic widths in those columns from cells spanning fewer columns.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Oh, the colspan sorter.  Right.  So in this case, we don't take the pref width from the colspan=2 cells in the first row when doing the colspan=2 cell in the second row (because they all have the same colspan).  And doing that would of course introduce row-order dependence into the algorithm.

The effect is that in fact we assign all the extra width from the colspan=2 cell in the second row to the first column...

Comment 17

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Does that match what WinIE does if you reverse the row order?

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: testcase 1a (with both row-orders)

(In reply to comment #17)
> Does that match what WinIE does if you reverse the row order?

Interesting... With the original row-order, IE7 matches branch.  With reversed row-order, IE7 matches trunk.

Here's a testcase that includes both row-orders.  Trunk and Branch handle both row-orders the same, and I'll post a screenshot of IE7's rendering.

Comment 19

[Daniel Holbert [:dholbert]]

Attachment: screenshot (IE7, with both row-orders)

Screenshot of IE7's rendering of just-posted testcase.

Notice that the rendering changes to match trunk when the row order switches.

Comment 20

[Daniel Holbert [:dholbert]]

RE comment 15 & comment 18, it looks like what trunk does here is reasonable, though it doesn't match Branch.

dbaron (and others):  Do we still want to match branch behavior here, or should we leave this as-is?

Comment 21

[Gabriel Chadwick]

Should it match branch ? Since the two are behaviours are OK the best thing should be to match branch to break the least websites possible. Since gecko 1.9 as not been released shouldn't mozilla do it's best to not break previous behaviour when the website as correct html ?

Comment 22

[Boris Zbarsky [:bzbarsky]]

Gabriel, matching branch would mean not matching IE or site expectations in a number of cases....  We used to have a whole bunch of bugs about colspanning cells not getting the right widths, and we fixed a lot of them since 1.8.

The only remaining issue is that IE's widths depend on row order, which seems a little unfortunate, so the algorithm David implemented is row-order-independent (as are those of Opera and Safari, as I recall; note that Safari's rendering is the same as the Gecko trunk rendering here).  It's not really possible to get the rendering "right" (defined as matching IE) while keeping row-order-independence, as the last testcase shows.

Comment 23

[Gabriel Chadwick]

Thank you for the explanation. Really appreciated. So if this is WONTFIX like I think it will be, just transfer it to tech evangelism...

Comment 24

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

Someone please file a followup bug as necessary.

Comment 25

[Gabriel Chadwick]

Will contact Desjardins.

Comment 26

[Gabriel Chadwick]

First contact with Desjardins they are working on the issue.

Comment 27

[Gabriel Chadwick]

Fixed by Desjardins with there new style.