290991 - Navigating to a slow loading page causes 1/2" high/thick gray "bar" on the bottom of the page above the status bar when the notification bar is present

Status: RESOLVED FIXED

(Core :: Layout, defect, P2)

Description

[u88484]

Problem: When I go to http://www.macromedia.com/shockwave/welcome/, let the page
load and then type a keyword into the address bar, hit enter. A huge bar appears
above the statusbar and it appears that the bar is the find toolbar becuase its
the same size although no buttons of input boxes are present. I can reproduce
this everytime on many different builds. No errors in jsconsole. And errors
happens on other pages just today I finally figured out that the keyword causes
it. The keyword I have is 'moz' for the adddress 'http://www.mozillazine.org'

Comment 1

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050419
Firefox/1.0+

can't reproduce

Comment 2

[Bryan]

(In reply to comment #1)
> Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050419
> Firefox/1.0+
> 
> can't reproduce

CONFIRMED!

I can usually "reproduce" this at http://www.cnn.com/ and many other sites. 
It's not something that's easily reproduced although I've noticed that this
occurs when the page you're navigating to takes a bit to "find", FF will display
this gray bar right above the status bar.  This is a blurb from my mozillazine
posting regarding this issue:

"I'm referring to the 1/2" high/thick gray "bar" on the bottom of the page.  It
has everything to do with the pop-up blocker if I remember correctly. This was
caused by a last minute "fix" to resolve an issue with the pop-up blocker right
before FF 1.0 was released. That "fix" was supposed to have been revisited to
address this and a few other issues if I recall correctly. This occurs in both
FF 1.0.x and 1.0+/1.1a1. " 

Click here for a screenshot of the issue:  

http://img167.echo.cx/my.php?image=graybar2dm.jpg

BUILD: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050524
Firefox/1.0+

DEFAULT Theme; NEW Profile; NO Extensions; 

Comment 3

[Martijn Wargers (dead)]

Probably this happens because you have a yellow bar with the message "Firefox
has prevented a popup" or "Additional Plugins are required to..." at the
previous page.
Then when you visit the other url (especially when that one loads slowly), the
yellow bar collapses and so everything needs to shift upwards. That's when you
get to see the awkward effect of that bottom gray bar.
It happens at the moment, when the old page is destroyed and a new page is
loading. So probably that is also part of the reason why it is happening.

Comment 4

[Bryan]

I started looking at when this "regressed" and was able to narrow it down to
between these two trunk builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041125
Firefox/0.9.1+  NO ISSUE

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a6) Gecko/20041205
Firefox/1.0+       ISSUE

This is when the Aviary merge began (Beast was on fire from between 11/25 and
12/05 according to Peter(6), which is why I couldn't find any builds between
those dates).  I then looked at when it regressed on Aviary and was able to
narrow it down to these two aviary builds:

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040710
Firefox/0.9.0+  NO ISSUE

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040711
Firefox/0.9.0+     ISSUE

I believe it might have been https://bugzilla.mozilla.org/show_bug.cgi?id=250716
that caused this issue.  Anything anyone can do to verify that would be great!

Bryan

Comment 5

[Martijn Wargers (dead)]

See:
http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#3200
tabbrowser.hideMessage is called when onlocationchange is happening.

Comment 6

[Martijn Wargers (dead)]

Attachment: Frame needed for testcase

Comment 7

[Martijn Wargers (dead)]

Attachment: Testcase

Comment 8

[u88484]

thank god someone created a testcase, I see this huge bar sooo much. The summary
should be update now since its not keywords that is causing this...that is just
how i was able to reproduce on the page list for the URL.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I bet this has to do with various code deciding to shut off painting during
pageload (document viewer, paint suppression, etc).  As a result, we resize the
frame, but don't actually repaint the new (bigger) area with anything but the
default color until the new page starts coming in...  I did try messing with the
nglayout initialpaintdelay without too much success, but removing the
DisableRefresh() calls in the document viewer seemed to make the flash shorter...

I wonder whether for now the UI should remove the box off a timeout (using the
paint delay value for the timeout may make sense).

Comment 10

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

Probably related to bug 285445.

Comment 11

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

Actually, I take back the comment about being related, and I'm not exactly sure
what's going on here.  It was suggested to me that this bug is Windows-only, but
the testcase shows the problem cross-platform.  And it's not clear to me how to
reproduce the original problem.

Comment 12

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

(In reply to comment #9)
> I bet this has to do with various code deciding to shut off painting during
> pageload (document viewer, paint suppression, etc).  As a result, we resize the
> frame, but don't actually repaint the new (bigger) area with anything but the
> default color until the new page starts coming in...

That shouldn't really be the case, since we should still be able to repaint the
old page.

Comment 13

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

Attachment: patch

This fixes the testcase and is a pretty reasonable explanation for the bug
(which I haven't really attempted to reproduce).

Do you think the performance/appearance tradeoff described in the comment is
one that we want to make?  My initial impression is that it is, but I'd be
interested to know if (a) you agree with that or (b) you think there's an
alternative fix that's better for performance.

Comment 14

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 190980 [details] [diff] [review]
patch

This looks pretty reasonable.  I still think the infobar-removal code should go
on a timeout like I suggested, since that will help with the performance aspect
somewhat...

Alternately, we could send some sort of notification right before we unsuppress
painting (but after we null out mPreviousViewer) and firefox could remove the
infobar from that notification.  That would still require this patch, in
general, and would still require us to reflow the new page when the infobar is
removed, but would be better than what we have now...

Comment 15

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

(In reply to comment #14)
> I still think the infobar-removal code should go
> on a timeout like I suggested, since that will help with the performance aspect
> somewhat...

I think that's probably not the best idea, since the paint suppression timeout
is a maximum -- if a page finishes loading before the timeout, it will
unsuppress sooner, and we don't want it moving around afterwards.

Comment 16

[Boris Zbarsky [:bzbarsky]]

Ah, good point.  So perhaps if we want to get fancy we should just do that
notification...

Comment 17

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

Fix checked in to trunk, 2005-08-02 13:19 -0700.

Comment 18

[Bryan]

Attachment: Screenshot showing 1/2" graybar is back when BFCache is enabled

The graybar is still there IF you have BFCACHE enabled.  I've got mine 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!!!

Comment 19

[Bryan]

Filed https://bugzilla.mozilla.org/show_bug.cgi?id=303327 which is similar to
this issue...