If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED WORKSFORME

Status

()

Core
Layout
--
trivial
RESOLVED WORKSFORME
12 years ago
9 years ago

People

(Reporter: Bryan, Unassigned)

Tracking

({helpwanted, qawanted})

Trunk
x86
Windows XP
helpwanted, qawanted
Points:
---
Bug Flags:
wanted-next +
blocking1.9 -
wanted1.9 -

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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!
(Reporter)

Comment 1

12 years ago
Created attachment 191558 [details]
1/2" Gray bar appears above status bar if BFCache is enabled and the steps to reproduce are followed...
(Reporter)

Updated

12 years ago
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
Blocks: 274784
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.

Comment 14

12 years ago
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.
(Reporter)

Comment 16

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

~B
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago12 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 → ---
(Reporter)

Comment 18

12 years ago
> 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

(Reporter)

Comment 19

11 years ago
Don't care about this anymore.
Status: REOPENED → RESOLVED
Last Resolved: 12 years ago11 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
Flags: blocking1.9?
[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"]

Updated

10 years ago
Duplicate of this bug: 389955

Updated

10 years ago
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)

Comment 25

10 years ago
(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.

Updated

10 years ago
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"]

Comment 27

10 years ago
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
Last Resolved: 11 years ago10 years ago
Resolution: --- → WORKSFORME

Comment 30

10 years ago
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

10 years ago
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 → ---

Comment 32

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

Comment 33

9 years ago
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
Last Resolved: 10 years ago9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.