162038 - framed pages drop reflow with load tab in background option

Status: VERIFIED FIXED

(Camino Graveyard :: Tabbed Browsing, defect)

Description

[RalphNumbers]

Google Image search breaks when you try to open one of the results in a new tab.
 The resulting tab seems to have one very small frame at the top, and a blank
frame below.  The page will display correctly if opened in the current tab, or
in a new window.

I think this *might* be a symptom of the same bug that mis-aligns some pages
when you open a link to a specific anchor tag target in a file (as opposed to
the file itself), putting the entire page off center in the window with a white
border arround it until you scroll.

Comment 1

[Steve Smart]

This Works for Me using 2002080905. I went to
http://images.google.com/images?q=Chimera&ie=ISO-8859-1&hl=en, right-clicked on
the first result, and chose open link in new tab. I also tried command-clicking
on the link to open it in a new tab. In both cases the result page loaded
properly, with all frames and images loading, and all links working.

Which result was this tested on and what build did it occur in?

Comment 2

[Max Horn]

I can confirm the problem in current CVS. It is keyed to the "Load opened 
window or tabs in the backgroun" option. If you enable it (like I normally 
do), the problem occurs, if you disable it (as Steve probably has it), it 
works just fine.
 

Comment 3

[saari (gone)]

bugs with loading tabs in background

Comment 4

[Steve Smart]

Thanks for clarifying this, Max. I can confirm that this bug does exist if (and
only if) you load a link in a background tab in 2002080905.

Comment 5

[Greg K.]

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

Comment 6

[Wincent Colaiuta]

As I said in the other (duplicate) bug 167074, you can also reproduce this using
URLs like the following:

http://groups.google.com/groups?hl=en&lr=&ie=ISO-8859-1&q=random+search

Comment 7

[Greg K.]

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

Comment 8

[Mike Pinkerton (not reading bugmail)]

we're probably just dropping the final reflow on the floor. resizing the window
at all fixes this.

Comment 9

[Michael Bryan Bell]

It also happens in the apple developer documentation- if you go to:
<http://developer.apple.com/techpubs/macosx/Cocoa/CocoaTopics.html>
and scroll down to the programming topics and open one of the links in a tab you
get the blank space. As Mr. Pinkerton stated with google they do show up if you
resize the window at all or reload. michael bryan bell

Comment 10

[Mike Pinkerton (not reading bugmail)]

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

Comment 11

[Mike Pinkerton (not reading bugmail)]

it has something to do with frames or iframes. can someone come up with a
reduced test case?

Comment 12

[sairuh (rarely reading bugmail)]

chris, have you seen this?

Comment 13

[Michael Blakeley]

Attachment: simple test case

This might help. I've trimmed out quite a bit of the content, fixed all of
tidy's complaints about the html, and packaged it up. There are four html files
in the tarball.

After unpacking the tarball, visit file:///.../162038-testcase/index.html (or
equivalent) and command-click on the link (make sure "load new tabs in
background" is in your prefs). Shift to the new tab and you should see a blank
page. Reload it and you'll see the frames.


100% reproducible for me with build 2002101104.

Comment 14

[Mike Pinkerton (not reading bugmail)]

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

Comment 15

[Mike Pinkerton (not reading bugmail)]

over to bryner. 

layout is setting the width/height of each <frame>'s nsView, and thus the
widget, to (0,0). I don't understand enough about layout to understand why. this
only happens when the page is opened in a new tab in the bg. 

Comment 16

[Brian Ryner (not reading)]

Attachment: patch

This is a merge of bzbarsky's patch for bug 48422 to the chimera branch.  There
were some bogus checks going on in nsHTMLFrameSetFrame::Reflow that caused it
to not recalculate the frame sizes on the first resize reflow after being sized
to 0,0.  This patch fixes that.

Comment 17

[Mike Pinkerton (not reading bugmail)]

wow, that's a pretty big patch. do we understand what it's doing and its effects
on the code?

Comment 18

[Brian Ryner (not reading)]

checked in.

Comment 19

[Greg K.]

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

Comment 20

[sairuh (rarely reading bugmail)]

vrfy'd fixed using the tests in comment 1 and comment 9. used 2002.12.04.04 on
10.2.2.