597774 - Clicking back navigates to the previous page but no painting happens (even after bug 592596, although much less often)

Status: VERIFIED FIXED

(Core :: Layout, defect)

Description

[Daniel C]

+++ This bug was initially created as a clone of Bug #592596 +++

See bug 592596 comment 10 through 12.

Comment 1

[Daniel C]

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.

Comment 2

[Timothy Nikkel (:tnikkel)]

(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).

Comment 3

[Daniel C]

(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?

Comment 4

[Timothy Nikkel (:tnikkel)]

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?

Comment 5

[Daniel C]

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?

Comment 6

[Daniel C]

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).

Comment 7

[Timothy Nikkel (:tnikkel)]

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.

Comment 8

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

I've seen this a few times recently (on Linux).

Comment 9

[Daniel C]

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 10

[Timothy Nikkel (:tnikkel)]

Using alt-(left arrow) might make this happen more often.

Comment 12

[Joe Drew (not getting mail)]

Bringing forward blocking request due to blocking request from duplicate bug 604111.

Comment 13

[Daniel C]

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.

Comment 14

[Timothy Nikkel (:tnikkel)]

I see it other places too, for the record.

Comment 15

[Chris AtLee [:catlee]]

I've noticed it mostly on buildbot waterfall pages.

Comment 16

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 17

[Timothy Nikkel (:tnikkel)]

I would not classify this as super-hard to reproduce. I feel like I could corner this given some time.

Comment 18

[Timothy Nikkel (:tnikkel)]

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.

Comment 19

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 20

[Timothy Nikkel (:tnikkel)]

Attachment: patch

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.

Comment 21

[Timothy Nikkel (:tnikkel)]

Attachment: patch v2

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.

Comment 22

[Timothy Nikkel (:tnikkel)]

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

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 510841 [details] [diff] [review]
patch v2

r=me with the spelling of "lying" fixed.

Comment 24

[Timothy Nikkel (:tnikkel)]

http://hg.mozilla.org/mozilla-central/rev/1f8628fd5547

Comment 25

[Timothy Nikkel (:tnikkel)]

This _is_ fixed. So yay for me.