303327 - 1/2" Gray bar appears above status bar with these steps (involves "popup blocked" information bar and bfcache)

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Bryan]

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

1/2" Gray bar appears above status bar if BFCache is enabled and the steps to
reproduce are followed.  This is similar to bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=290991 which has been resolved.

Reproducible: Always

Steps to Reproduce:
Verify that you have BFCache enabled.  Mine is set to 5.

1) Launch FF (Latest build)
2) Verify that the "Information Bar" is shown when pop-ups are blocked!!!
3) CLEAR your cache
4) Navigate to http://www.news.com/ and let it load completely
5) Navigate to http://www.cnn.com/ and let it load completely
6) Navigate to http://www.newscientist.com/ and let it load completely
7) Click the "Back" button on the toolbar TWICE to navigate back to
http://www.news.com/
8) Observe a 1/2" gray bar right above the status bar as seen in the screenshot
above!!!
Actual Results:  
1/2" Gray bar appears above status bar if BFCache is enabled and the steps to
reproduce are followed.  I imagine quite a few ppl will run into this once we go
live with 1.5.

Expected Results:  
Display the page normally and as expected!

Comment 1

[Bryan]

Attachment: 1/2" Gray bar appears above status bar if BFCache is enabled and the steps to reproduce are followed...

Comment 2

[Ria Klaassen (not reading all bugmail)]

I see the same.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050803
Firefox/1.0+ ID:2005080322

Comment 3

[Boris Zbarsky [:bzbarsky]]

Please make all bfcache issues block bug 274784.

Issues that only arise with bfcache enabled don't block beta.

Comment 4

[Martijn Wargers (dead)]

I could not reproduce with the steps described.
However I can reproduce with following steps:
- Visit http://simon.incutio.com/archive/2003/08/11/selfContained
- Click on "Self contained data: URI kitchen" link
- Paste in textarea: <script>window.open('http://google.com');</script>
- Click on "generate" button.
- Now click on "The URI" link.
- Go back
- Click on "generate" button (something weird is happening here, I get the feeling)
- Click another time on "generate" button
- Click on "The URI" link
- Go back
- Go back

Comment 5

[Ria Klaassen (not reading all bugmail)]

The bug only shows after the second time you try the testcase. 
You need to have visited the second address (http://www.cnn.com/) before with
cookies enabled.
One of the cookies set by this domain or advertisers on this site triggers the
problem.
If I delete cookies.txt everytime after closing Firefox, I don't see this
problem anymore.
Or I am just very tired.

Comment 6

[Ria Klaassen (not reading all bugmail)]

(In reply to comment #4)

Confirmed.

Comment 7

[Ria Klaassen (not reading all bugmail)]

Regression between 2005080207 and 2005080222 (both tests).

Comment 8

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

This is related to the code in nsDocShell::RestoreFromHistory (and
nsDocShell::CaptureState).  There's even a comment there about it.  I wonder if
that code would be better off calling SetBounds on the document viewer rather
than the widget (although currently it probably doesn't make much difference). 
It also seems like it might be better to use the bounds from the viewer being
replaced rather than bounds saved in session history.

Comment 9

[Serge Gautherie (:sgautherie)]

I see this bug (Gray area, with BFCache on) in SeaMonkey too.

I'm quite sure about SMv1.1a Trunk, and I think I saw it in SMv1.0a Branch too:
I'll add buildID when I see it once more.

Comment 10

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b4) Gecko/20050910 SeaMonkey/1.0a]
(release) (W98SE)

How I get the bug (not always, but often):
*I'm on <www.battle-arenas.net>:
 (this page is a frameset)
*I go back directly to <about:> page:
 The gray area could have the height of the previous top frame !??

Comment 11

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)
> *I'm on <www.battle-arenas.net>:

Rather <dev.battle-arenas.net>; and it's the only "tab" in my browser.

Comment 12

[Serge Gautherie (:sgautherie)]

(In reply to comment #11)
> Rather <dev.battle-arenas.net>; and it's the only "tab" in my browser.

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050917 SeaMonkey/1.1a]
(nightly) (W98SE)

On Trunk too.

Comment 13

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051124 SeaMonkey/1.5a] (nightly) (W98SE)

Somehow, I (still) got this bug once today.

Comment 14

[Justin Watt]

I'm experiencing something like this bug, after a clean slate install of Firefox 1.5, the only difference being the gray bar was permanently visible below the status bar from first launch.

Screenshots at the bottom of this blog post:
http://justinsomnia.org/2005/12/whats-so-cool-about-firefox-15/

Comment 15

[Serge Gautherie (:sgautherie)]

(In reply to comment #14)
> I'm experiencing something like this bug, after a clean slate install of
> Firefox 1.5, the only difference being the gray bar was permanently visible
> below the status bar from first launch.

Could be but I doubt it:
the red "^" character rather indicate an "XML / Chrome" issue, afaik.

Comment 16

[Bryan]

Appears to be fixed in current branch builds as I cannot reproduce this issue!

~B

Comment 17

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20060304 SeaMonkey/1.5a] (nightly) (W98SE)

I still got one today:
on <www.battle-arenas.net>, closing a 2nd tab, having the first tab take back the full browser window.

This is rare, but it happens from times to times.

Comment 18

[Bryan]

> This is rare, but it happens from times to times.

I'm seeing this again.  Need to figure out steps to reproduce.  Happens rarely.

Bryan

Comment 19

[Bryan]

Don't care about this anymore.

Comment 20

[Ryan VanderMeulen [:RyanVM]]

This is easily reproducible if you go to bug 367247, load the testcase, then hit back.

Comment 21

[Ryan VanderMeulen [:RyanVM]]

Should have noted that I'm testing with the trunk

Comment 22

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070225 SeaMonkey/1.5a] (nightly) (W2Ksp4)

Got it once.

Comment 23

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

I had a fully reproducable testcase for this bug around the time I landed the reflow branch; I think there's a comment in another bug somewhere pointing to this one, but I never mentioned it here.

Comment 25

[Jesse Ruderman]

(In reply to comment #23)
> I had a fully reproducable testcase for this bug around the time I landed the
> reflow branch; I think there's a comment in another bug somewhere pointing to
> this one, but I never mentioned it here.

I'm going to guess bug 290991 comment 13 (found by searching for references to this bug) or bug 264683 comment 4 (found by searching for you saying the phrase "information bar").

The dup also has a set of steps that I can reproduce the bug with.

Comment 27

[Steve Chapel]

I haven't seen this problem for a while and I cannot reproduce with Firefox 3 beta 2 on Windows XP. Does anyone have steps that can still reproduce the problem?

Comment 28

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

I can't reproduce this. If no-one can, we should close this bug.

Comment 29

[Martijn Wargers (dead)]

This is worksforme, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041206 Minefield/3.0pre

Please reopen if someone can still reproduce.

Comment 30

[[e-mail]]

This won't be reproducible on trunk because a) it was originally worked around by never calling removeAllNotifications(true); b) when I implemented removeTransientNotifications I always called removeNotification instead of removeChild to avoid special-casing when there was a notification to keep.

Comment 31

[Steve Chapel]

I have seen this a few times this year with Firefox 3 betas, always after going to the Urban Legends Reference Pages. I've managed to reproduce it at least twice with Firefox 3 RC1.

Reproducible: Sometimes

Steps to reproduce:

1. Go to http://snopes.com/
2. Click on the What's New? link
3. Scroll down and click on one of the links to a new story
4. Click the Back button three times (perhaps the timing is important here, I generally let the page load fully on each click)

It looks like the problem depends on the fact that the popup blocker notification comes up on multiple pages, and one or two of these pages has a horizontal scroll bar. This means you cannot keep trying to reproduce the problem during a short time, because the second time you go to the main page and the What's New? page, you will not receive a popup. You may need to wait until the next day (or at least a few hours) before trying again at snopes.

I'm changing the severity to trivial, as it's a cosmetic bug that quickly fixes itself. I will try to create a reduced testcase that always generates a popup and a horizontal scrollbar so the problem can be reproduced more reliably.

Comment 32

[Worcester12345]

WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008053002 SeaMonkey/2.0a1pre ID:2008053002

Comment 33

[Steve Chapel]

I was never successful in creating a reduced testcase. I also haven't seen the problem in the Firefox 3.1 betas, despite using both betas and going to the Urban Legends Reference Pages at least a few times a week for the past several months. I'll resolve this as WFM again.