295527 - Loading EVE Online site without flash plugin causes rendering error

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect)

Description

[Geoff Wilson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050523 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050523 Firefox/1.0+

If you navigate to the EVE Online website without the flah player plugin
installed  www.eve-online.com, on load the page just keeps increasing in
horizonatal lenght, once flah is installed the website displays fiine

Reproducible: Always

Steps to Reproduce:
1. Remove Flash Plugin / Use clean install
2. Go to www.eve-online.com
3.

Actual Results:  
website constantly gains horizontal width 

Expected Results:  
website should display fine with the space for the flash movie just showing the
plugin required green box thingy

Comment 1

[Geoff Wilson]

Attachment: Website Without Flah Plugin

Comment 2

[Geoff Wilson]

Attachment: What it should look like

Comment 3

[Matthias Versen [:Matti]]

-> PFS

Comment 4

[Martijn Wargers (dead)]

This regressed between 2005-03-30 and 2005-03-31:
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-03-30+06%3A00%3A00&maxdate=2005-03-31+08%3A00%3A00&cvsroot=%2Fcvsroot
Possible culprits: bug 288117, bug 245349 and bug 288222.

Comment 5

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 6

[Martijn Wargers (dead)]

The testcase case has an <embed> with width="100%" inside a table.
This is when people are starting to talk about mew and stuff (not that I know
what it means).

Comment 7

[Hermann Schwab]

I´m seeing this bug in Deerpark, but not in 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050524

Comment 8

[Bernd]

yeah this differs between ff and the suite where it is wfm, ff is doing
something fancy but I have no idea where and how that does happen. 

Comment 9

[Martijn Wargers (dead)]

Attachment: what I backed out

when I back out this part, the bug doesn't happen.
So it looks like this is a regression of bug 245349.

Comment 10

[Bernd]

I don't have a ff build, 

SizeAnchor is evil as stated in the code
 
       // SizeAnchor() is seriously evil as it ends up setting an
       // attribute (through the style changes that it does) while
       // we're in reflow. This is also seriously evil, as it pulls
       // that reflow command out of the reflow queue, as leaving it
       // there can get us into infinite loops while reflowing object
       // frames for missing plugins.

Adding jst to CC as he checked in this code, what happens here is exactly what
the comment promises

Comment 11

[Prisacari Sergey]

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

Comment 12

[Asa Dotzler [:asa]]

Arron, can you look into this please?

Comment 13

[Aaron Leventhal]

All my patch in bug 245349 did was change the <div> which was already there to
use an <a>. Because of that, I renamed jst's method to SizeAnchor. Since my <a>
is styled as display:block, it should just work the same.

I wish jst or someone a little more familiar with layout would look into it.
Otherwise, I'll just backout bug 245349, since I don't really have time to
investigate this weirdness.

Another fix that is possible now is to go back to the code which used a div, and
now use SetAttributeNS to assign it xhtml2:role="wairole:link". Also set the
tabindex to 0. Maybe that would fix it, although we wouldn't be looking at the
root of the problem.

Jst, why would your "evil" SizeDiv() not work if I change it to an <a> with
display:block?

Comment 14

[Boris Zbarsky [:bzbarsky]]

My bets here would be on bug 288117 (and I thought we had a bug report on this
already...)

Comment 15

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

I think what happens here is the following sequence:

Child has some width:NNNpx set in its style
**** Reflow K
-- Table reflows the objectframe with unconstrained width
  -- Objectframe does GetDesiredSize, gets the default width (320)
  -- Sets the child's style to width:320px (posts restyle event)
  -- We reflow the child, its reflow state mComputedWidth is taken from the old
style context = NNNpx
  -- Child returns MEW NNN+12px (because it includes border+padding!)
  -- table decides the cell needs to be NNN+12px
-- Table reflows the objectframe with constrained width NNN+12px
  -- Objectframe does GetDesiredSize, gets the new width NNN+12px
  -- Sets the child's style to width:NNN+12px (posts another restyle event,
which is coalesced I guess)
  -- We reflow the child, its reflow state mComputedWidth is taken from the same
old style context (because we haven't done the restyle event yet) = NNNpx
  -- Child returns MEW NNN+12px again
-- Table is done

Now the restyle event fires, the table has NNN+12px set in its style context,
and we do another iteration.

Comment 16

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

I think at the least, SizeAnchor should subtract the child's border and padding
before setting mComputedWidth/mComputedHeight.

Ideally all this code would be thrown to the bottom of the sea

Comment 17

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

Attachment: fix

This fixes the bug. It even makes sense.

Comment 18

[Boris Zbarsky [:bzbarsky]]

All this code will be at the bottom of the sea by the time 1.9a wraps up....

Comment 19

[Martijn Wargers (dead)]

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

Comment 20

[Martijn Wargers (dead)]

The fix also fixes the too big placeholders I was seeing at various places of
the web (which caused it to partly overlap text, etc).

Comment 21

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

Comment on attachment 189990 [details] [diff] [review]
fix

fixes a layout regression

Comment 22

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

checked in

Comment 23

[Henrik Skupin [:whimboo][⌚️UTC+2]]

Works fine with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4)
Gecko/20050725 Firefox/1.0+

v.

Comment 24

[Martijn Wargers (dead)]

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