Closed Bug 303327 Opened 15 years ago Closed 11 years ago

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

Categories

(Core :: Layout, defect, trivial)

x86
Windows XP
defect
Not set
trivial

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: BoxerBoi76, Unassigned)

References

Details

(Keywords: helpwanted, qawanted, Whiteboard: [Serge, last time: build "Gecko/20070328 SeaMonkey/1.5a"])

Attachments

(1 file)

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!
Flags: blocking1.8b4?
Assignee: nobody → dbaron
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
Please make all bfcache issues block bug 274784.

Issues that only arise with bfcache enabled don't block beta.
Assignee: dbaron → nobody
Flags: blocking1.8b4?
Keywords: helpwanted, qawanted
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
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.
(In reply to comment #4)

Confirmed.
Regression between 2005080207 and 2005080222 (both tests).
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.
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
[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 !??
(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.
(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.
[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.
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/
(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.
Appears to be fixed in current branch builds as I cannot reproduce this issue!

~B
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → VERIFIED
[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.
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
> 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

Don't care about this anymore.
Status: REOPENED → RESOLVED
Closed: 14 years ago14 years ago
Resolution: --- → INVALID
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
Status: REOPENED → NEW
This is easily reproducible if you go to bug 367247, load the testcase, then hit back.
Should have noted that I'm testing with the trunk
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070225 SeaMonkey/1.5a] (nightly) (W2Ksp4)

Got it once.
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.
Flags: blocking1.9? → blocking1.9-
Whiteboard: [wanted-1.9]
Whiteboard: [wanted-1.9] → [wanted-1.9] [Serge, last time: build "Gecko/20070328 SeaMonkey/1.5a"]
Duplicate of this bug: 389955
Summary: 1/2" Gray bar appears above status bar if BFCache is enabled and the steps to reproduce are followed... → 1/2" Gray bar appears above status bar with these steps (involves "popup blocked" information bar and bfcache)
(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.
Duplicate of this bug: 395572
Flags: wanted1.9+
Whiteboard: [wanted-1.9] [Serge, last time: build "Gecko/20070328 SeaMonkey/1.5a"] → [Serge, last time: build "Gecko/20070328 SeaMonkey/1.5a"]
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?
I can't reproduce this. If no-one can, we should close this bug.
Flags: wanted1.9-
Flags: wanted1.9+
Flags: wanted-next+
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.
Status: NEW → RESOLVED
Closed: 14 years ago12 years ago
Resolution: --- → WORKSFORME
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.
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.
Severity: normal → trivial
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008053002 SeaMonkey/2.0a1pre ID:2008053002
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.
Status: REOPENED → RESOLVED
Closed: 12 years ago11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.