Closed
Bug 290991
Opened 19 years ago
Closed 19 years ago
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
Categories
(Core :: Layout, defect, P2)
Tracking
()
RESOLVED
FIXED
mozilla1.8beta4
People
(Reporter: u88484, Assigned: dbaron)
References
()
Details
(Keywords: testcase, Whiteboard: [patch])
Attachments
(4 files)
388 bytes,
text/html
|
Details | |
546 bytes,
application/vnd.mozilla.xul+xml
|
Details | |
1.52 KB,
patch
|
bzbarsky
:
review+
roc
:
superreview+
benjamin
:
approval1.8b4+
|
Details | Diff | Splinter Review |
267.72 KB,
image/png
|
Details |
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•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050419 Firefox/1.0+ can't reproduce
(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;
Flags: blocking1.8b3?
Flags: blocking-aviary1.1?
Comment 3•19 years ago
|
||
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.
Component: Find Toolbar / FastFind → Layout
Product: Firefox → Core
Updated•19 years ago
|
Assignee: firefox → nobody
Flags: blocking1.8b3?
QA Contact: layout
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•19 years ago
|
||
See: http://lxr.mozilla.org/seamonkey/source/browser/base/content/browser.js#3200 tabbrowser.hideMessage is called when onlocationchange is happening.
Comment 6•19 years ago
|
||
Comment 7•19 years ago
|
||
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.
Updated•19 years ago
|
Summary: loading page via a keyword causes huge bar above statusbar → 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
Updated•19 years ago
|
Flags: blocking1.8b4?
Comment 9•19 years ago
|
||
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).
Updated•19 years ago
|
Flags: blocking-aviary1.1?
Assignee | ||
Comment 10•19 years ago
|
||
Probably related to bug 285445.
Updated•19 years ago
|
Flags: blocking1.8b4? → blocking1.8b4+
Updated•19 years ago
|
Assignee: nobody → dbaron
Whiteboard: [needs windows machine]
Assignee | ||
Comment 11•19 years ago
|
||
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.
Assignee | ||
Comment 12•19 years ago
|
||
(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.
Assignee | ||
Comment 13•19 years ago
|
||
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.
Attachment #190980 -
Flags: superreview?(roc)
Attachment #190980 -
Flags: review?(bzbarsky)
Assignee | ||
Updated•19 years ago
|
Status: NEW → ASSIGNED
Priority: -- → P2
Whiteboard: [needs windows machine] → [patch]
Target Milestone: --- → mozilla1.8beta4
Comment 14•19 years ago
|
||
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...
Attachment #190980 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 15•19 years ago
|
||
(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•19 years ago
|
||
Ah, good point. So perhaps if we want to get fancy we should just do that notification...
Attachment #190980 -
Flags: superreview?(roc) → superreview+
Assignee | ||
Updated•19 years ago
|
Attachment #190980 -
Flags: approval1.8b4?
Updated•19 years ago
|
Attachment #190980 -
Flags: approval1.8b4? → approval1.8b4+
Assignee | ||
Comment 17•19 years ago
|
||
Fix checked in to trunk, 2005-08-02 13:19 -0700.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Comment 18•19 years ago
|
||
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•19 years ago
|
||
Filed https://bugzilla.mozilla.org/show_bug.cgi?id=303327 which is similar to this issue...
You need to log in
before you can comment on or make changes to this bug.
Description
•