Closed
Bug 597774
Opened 14 years ago
Closed 14 years ago
Clicking back navigates to the previous page but no painting happens (even after bug 592596, although much less often)
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
VERIFIED
FIXED
People
(Reporter: djcater+bugzilla, Assigned: tnikkel)
References
Details
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
bzbarsky
:
review+
|
Details | Diff | Splinter Review |
+++ This bug was initially created as a clone of Bug #592596 +++ See bug 592596 comment 10 through 12.
Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100923 Firefox/4.0b7pre Just hit this again. It was again here on Bugzilla, going from the History page (show_activity.cgi) of a bug back to the bug itself. This is the first time I've hit it since filing, which was almost 5 days ago so this is difficult to reproduce. I think I hit the back button as soon as the page had finished loading, maybe slightly before as I realised that I didn't actually need to look at that page.
Assignee | ||
Comment 2•14 years ago
|
||
(In reply to comment #1) > I think I hit the back button as soon as the page had finished loading, maybe > slightly before as I realised that I didn't actually need to look at that page. That is interesting. What if you set the pref "nglayout.initialpaint.delay" to 10000 (be sure to reset this pref when you are done testing) and try to reproduce? It doesn't need to be bugzilla, try any slow loading site (slow because it needs to load a lot of stuff or because the server is slow).
(In reply to comment #2) > (In reply to comment #1) > > I think I hit the back button as soon as the page had finished loading, maybe > > slightly before as I realised that I didn't actually need to look at that page. > > That is interesting. What if you set the pref "nglayout.initialpaint.delay" to > 10000 (be sure to reset this pref when you are done testing) and try to > reproduce? It doesn't need to be bugzilla, try any slow loading site (slow > because it needs to load a lot of stuff or because the server is slow). Unless I don't understand what this pref is supposed to do, I don't think it's working properly for me, even on a clean profile and after restarting. I added a new integer pref in about:config called nglayout.initialpaint.delay and set it to 10000. All page loads seem to paint as quickly as before, _except_ error pages, which paint after a 10 second delay. If I open a new tab and try to load http://www.non-existent.example.com/ then the content area is completely white for 10 seconds until the error page appears. If I open a new tab and try to load http://mxr.mozilla.org/ it appears almost straight away. about:neterror appears straight away though. http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#2774 is where the pref is read, which, if the pref is not found, falls back to the default of 250 ms which is defined here: http://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#1284. The pref does not appear by default in about:config. Have I done something wrong or is this pref not actually working at the moment on trunk?
Assignee | ||
Comment 4•14 years ago
|
||
Sorry for not explaining further. The pref is working as expected. (Well the error pages thing should be fixed, but it is another bug.) If we finish loading the document before the nglayout.initialpaint.delay time has expired then we ignore it and go ahead and show the document (it's ready after all, no need to delay showing it). I was hoping that by increasing the delay you might get a longer window in which to trigger the bug for some slowly loading sites, did you have any luck with that?
OK thanks, I misunderstood what the delay was. It makes the initial paint happen after the delay _or_ the page has finished loading, which makes sense. I thought it caused every page to wait for the delay before painting. Unfortunately, I haven't been able to reproduce this bug again yet, even with the long delay. I'm not sure how it would help though because for this bug to occur the next page has to be painted and then going back wouldn't repaint the first page. However, clicking a link doesn't unpaint the current page so going back during the extended window just keeps the current page displayed. Are there any environment settings or similar that I can run with so that the next time it shows up I can give you something useful?
Mozilla/5.0 (X11; Linux i686; rv:2.0b7pre) Gecko/20100927 Firefox/4.0b7pre It happened again, same as comment 1 (going from a bug history page back to the bug).
Assignee | ||
Comment 7•14 years ago
|
||
I see this fairly often. Either people have a hard time finding or describing this bug (because I would expect more CCs and dupes), or most people don't see this as often as I do.
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
Interesting. I did see this a couple more times shortly after comment 6. However, I always used to use Gentoo as my main OS but I switched to Ubuntu (10.10) in October and haven't experienced this bug since. I use the latest nightlies as my main browser every day, and this was a bug that I used to experience a few times per week.
Comment 12•14 years ago
|
||
Bringing forward blocking request due to blocking request from duplicate bug 604111.
blocking2.0: --- → ?
Reporter | ||
Comment 13•14 years ago
|
||
Bug 604111 mentions this happening on Bugzilla, which is the only place that I ever saw it happening. Is there anything here that would cause this to happen more than elsewhere? https? I thought for a moment that secure pages weren't held in the bfcache but that doesn't seem to be true.
I don't think I've ever seen this. If it's super-hard to reproduce, I'm not sure what we're going to be able to do about it.
Assignee | ||
Comment 17•14 years ago
|
||
I would not classify this as super-hard to reproduce. I feel like I could corner this given some time.
Assignee | ||
Comment 18•14 years ago
|
||
For example it doesn't seem to be very hard to trigger this bug on webpages served from the poorly coded webserver running on my underpowered DVR.
We're not going to block on this given that the workaround is so intuitive. However if someone can figure this out, it'd be lovely to land a fix. But of course blockers should take priority.
Assignee | ||
Comment 20•14 years ago
|
||
While working on bug 631848 I figured this bug out, so it wasn't like I was working on non-blockers. :) I'm not sure this fixes this bug, but I think it will. This is basically the same patch as bug 631848 except when documents are coming out of the bfcache.
Assignee: nobody → tnikkel
Attachment #510222 -
Flags: review?(roc)
Attachment #510222 -
Flags: approval2.0?
Attachment #510222 -
Flags: review?(roc)
Attachment #510222 -
Flags: review+
Attachment #510222 -
Flags: approval2.0?
Attachment #510222 -
Flags: approval2.0+
Assignee | ||
Comment 21•14 years ago
|
||
nsDocShell::FinishRestore removes from a loadgroup, which can flush and kill the views. So null them out and re-get them. Just asking for review on the changes from the first version of the patch.
Attachment #510222 -
Attachment is obsolete: true
Attachment #510841 -
Flags: review?(bzbarsky)
Assignee | ||
Comment 22•14 years ago
|
||
I checked that all the other local variables in this function are nsCOMPtr, so the ones I null out are the only ones that could hold a stale pointer.
Comment 23•14 years ago
|
||
Comment on attachment 510841 [details] [diff] [review] patch v2 r=me with the spelling of "lying" fixed.
Attachment #510841 -
Flags: review?(bzbarsky) → review+
Assignee | ||
Comment 24•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/1f8628fd5547
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•