315369 - frameset does not display when top.window.outerWidth or top.window.outerHeight called before drawing

Status: RESOLVED FIXED

(Core :: DOM: HTML Parser, defect, P1)

Description

[klassej]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051104 Camino/1.0+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051104 Camino/1.0+

The page renders fine in Safari etc. but doesn't show in Camino.

Reproducible: Always

Steps to Reproduce:
1. Open http://www.svenskadator.se/ in Camino.
2. 
3.

Comment 1

[Jasper]

WFM on the branch 2005103104 (1.0a1+)

Comment 2

[Jasper]

And it's indeed borken on the trunk using 2005110608 (1.0+)

Comment 3

[Jasper]

Confirming. Sam or Pink can you tell me if this should be bounced to the Core?

Comment 4

[Chris Lawson (gone)]

Possibly a trunk regression of bug 312942, bug 307821, or bug 309712 (all three of which were Core bugs, btw).

cl

Comment 5

[Samuel Sidler (old account; do not CC)]

When did this break?

Comment 6

[Wevah (Nate Weaver)]

It looks like the <script> is screwing it up.

Comment 7

[Wevah (Nate Weaver)]

Maybe not; hmm.

Comment 8

[Wevah (Nate Weaver)]

Nope, that's definitely it. Removing the <script> tag makes the page load.

Comment 9

[Wevah (Nate Weaver)]

Calling top.window.outerWidth or top.window.outerHeight before the page has started drawing causes the page to not render when there's a frameset!

Reduced testcase forthcoming.

Comment 10

[Wevah (Nate Weaver)]

Calling top.window.outerWidth or top.window.outerHeight before the page has started drawing causes the page to not render when there's a frameset!

Reduced testcase forthcoming.

Comment 11

[Wevah (Nate Weaver)]

Attachment: Reduced testcase

Comment 12

[Wevah (Nate Weaver)]

This does *not* occur in the latest Firefox trunk build, so it's definitely Camino-only.

(Sorry about the double post above; the radio buttons are a bit too close to the "Commit" button.)

Comment 13

[klassej]

(In reply to comment #12)
> This does *not* occur in the latest Firefox trunk build, so it's definitely
> Camino-only.
> 
> (Sorry about the double post above; the radio buttons are a bit too close to
> the "Commit" button.)
> 

Updated to:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8) Gecko/20051108
Camino/1.0b1

It now works fine, the content of the page shows.

Comment 14

[Wevah (Nate Weaver)]

This still occurs. It's trunk only; 1.0b1 is on a branch. Reopening.

Comment 15

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

This needs a regression window (it's still broken on the trunk)--and then we can bug layout folks ;)

Comment 16

[froodian (Ian Leue)]

This broke between the 2005-08-24 nightly and the 2005-08-25 nightly.

Comment 17

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #16)
> This broke between the 2005-08-24 nightly and the 2005-08-25 nightly.

Checkins in that window: http://tinyurl.com/g9oel

The most promising-looking checkin in that group (to me) was one of the split-window bugs, but it was fixed on the trunk and 1.8 (pre-1.8.0), so that can't be it.  Boris, do you have any idea which one might have caused this (Camino-Trunk-only) bug?

Comment 18

[Boris Zbarsky [:bzbarsky]]

The checkin for bug 253951 could have done it.  Note that that caused regressions which were fixed -- bug 306660, bug 312097, bug 321751.  Those are similar in concept to the problem you're describing here...

Are you seeing any of those three bugs in Camino, by any chance?

Comment 19

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #18)
> The checkin for bug 253951 could have done it.  Note that that caused
> regressions which were fixed -- bug 306660, bug 312097, bug 321751.  Those are
> similar in concept to the problem you're describing here...

Bug 306660 (URL): works, 1.8.0 and trunk
Bug 312097 (URL): works, 1.8.0; broken trunk
Bug 321751, attachment 207017 [details]: broken 1.8.0 (as expected*), works trunk.
(* the whole body is repainted brown on returning to the page after switching tabs)
Bug 321751, attachment 208051 [details]: broken, 1.8.0 (as expected, when loaded in about:blank), works on trunk


I put the full table above to help me keep track of what I was seeing, so it's a lot of maybe-useless information ;)

I think the only useful bit of info in the "chart" is that bug 312097 is still broken on the trunk in Camino, which would make it the closest cousin to this bug on that basis.

Comment 20

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Oops, I meant to put 1.8.1 results, too, before I posted; they're identical to the 1.8.0 results on every case (as, I think, is expected in all those cases).

Comment 21

[Boris Zbarsky [:bzbarsky]]

Ah, bug 312097 is broken on trunk in Firefox too, and I've managed to reproduce this bug in TestGtkEmbed.  So we're in business.  I see what happened here...   It's a regression from bug 311785, more or less.

Comment 22

[Boris Zbarsky [:bzbarsky]]

Attachment: This seems to fix it...

Comment 23

[Boris Zbarsky [:bzbarsky]]

I'd appreciate a test of that patch in Camino too, of course.

Comment 24

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #23)
> I'd appreciate a test of that patch in Camino too, of course.

I just rebuilt Camino with your patch, and it does indeed fix both the testcase here and the one in bug 312097.  Thanks Boris!

Comment 25

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 217038 [details] [diff] [review]
This seems to fix it...

So the bug is in how we grab mFrameset? (in any case this seems like a resonable thing to do since mFrameset doesn't need to be set twice)

Comment 26

[Boris Zbarsky [:bzbarsky]]

Yeah, the bug is that now we're setting mFrameset before the place where we're checking it (without this patch).  We need to check it first.

Comment 27

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Doh! Of course, i'm with you now.

Comment 28

[Boris Zbarsky [:bzbarsky]]

Fixed.