Closed Bug 597774 Opened 9 years ago Closed 9 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)

defect
Not set

Tracking

()

VERIFIED FIXED
Tracking Status
blocking2.0 --- .x+
status2.0 --- wanted

People

(Reporter: djcater+bugzilla, Assigned: tnikkel)

References

Details

Attachments

(1 file, 1 obsolete file)

+++ 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.
(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?
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).
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
I've seen this a few times recently (on Linux).
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.
Using alt-(left arrow) might make this happen more often.
Duplicate of this bug: 604111
Bringing forward blocking request due to blocking request from duplicate bug 604111.
blocking2.0: --- → ?
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 see it other places too, for the record.
I've noticed it mostly on buildbot waterfall pages.
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.
I would not classify this as super-hard to reproduce. I feel like I could corner this given some time.
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.
blocking2.0: ? → .x
status2.0: --- → wanted
Attached patch patch (obsolete) — Splinter Review
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+
Attached patch patch v2Splinter Review
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)
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 on attachment 510841 [details] [diff] [review]
patch v2

r=me with the spelling of "lying" fixed.
Attachment #510841 - Flags: review?(bzbarsky) → review+
http://hg.mozilla.org/mozilla-central/rev/1f8628fd5547
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
This _is_ fixed. So yay for me.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.