Bug 13892 - White page flash when reloading page (not present in Gecko browsers)
Summary: White page flash when reloading page (not present in Gecko browsers)
Status: RESOLVED DUPLICATE of bug 17998
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-27 14:38 PDT by Andrew
Modified: 2008-11-13 15:48 PST (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew 2007-05-27 14:38:28 PDT
Extensive browsing has caused me to notice this more and more.

Refreshes often cause flashing of un-styled content where as simply loading the page again by clicking on a link to it causes the content to renew but without the flashing of a "proper" refresh. Gecko seems to handle both cases in the same way (no flashing).

I had a talk with M. Rowe about this on IRC and he said:

"I think Safari's 'Reload' means 'Reload the page ignoring the cache' while to Gecko it means 'Reload the main resource ignoring the cache, feel free to use it for any subresources'"

Mark then expressed his view that Webkit's was the "correct" way to ensure the page refresh was just that. However Gecko's way is much smoother and results in much faster "perceived" refreshing of the page. From an everyday browsing POV the Gecko way without doubt seems preferred. Mark encouraged me to submit a report.

I notice this on quite a few sites but this page seems to illustrate it best:

http://community.nethosted.co.uk/

If you hit Cmd-R a few times you'll see un-styled content. If you instead do a Cmd-L then hit enter no flash occurs but the page is still renewed from the server. I find the latter behaviour smoother and therefore preferable, Gecko also performs a refresh this way as I've mentioned before. Anything that improves the speed of a refresh is surely a good thing.
Comment 1 Dave Hyatt 2007-05-27 15:19:15 PDT
Note that I agree that our reload is too slow.  I've never liked WebKit's behavior, since I think excluding images from a reload is not a big deal (and results in vastly improved reload performance).  I would probably include everything else (CSS, scripts, subframe HTML, etc.) while allowing images only to load from cache without verification.

Comment 2 Dave Hyatt 2007-05-27 15:21:44 PDT
This isn't really FOUC.  This is just normal page loading.  Gecko and WebKit both look pretty ugly on a fresh load of the page.  Gecko doesn't look ugly on refresh, but that's because its refresh is incomplete.  You have to hit Shift+Reload to get a real refresh in Gecko.

The problem with Gecko's approach is that refreshes can be incomplete, and people have to discover the secret Shift modifier key in order to get real refreshes.  To avoid this problem we just treat all refreshes as full.  This results in a slower refresh than Gecko, but also in a refresh that is never incomplete or wrong.

Comment 3 Andrew 2007-05-27 16:07:26 PDT
Thanks for your replies. Is it your view that although a "normal" refresh in Gecko ends up loading items such as images from a the cache that in the vast majority of refresh situations this wouldn't be an issue and would result in much improved refresh performance (if only perceived)? It is my opinion that the behaviour of refresh should be aimed at making the perceived speed of Webkit greater than all others (a main Webkit goal) and loading items from cache clearly aids this aim. I'm not sure really if the goal of Webkit is to be the fastest rendering engine from a "statistical" or a "perceived" pov (both would be nice!)?

I don't mind if this bug report turns into a bit of a scratch pad to help improve the way Webkit refreshes/reloads pages. For example Opera allows for the user to specify a time limit for caching different types of items (images/documents). I actually much prefer the Gecko way of doing things to either Opera or Webkit's ways. 

To sum up: I think the refresh behaviour should be the smoothest/least jarring one and the user should have the option to perform a "complete" refresh by holding down a modifier key (isn't this also the way IE does it? So the vast majority of users are trained to already hold down a key to force a full refresh).
Comment 4 Brady Eidson 2007-05-27 23:11:33 PDT
"I think the refresh behaviour should be the smoothest/least jarring
one and the user should have the option to perform a "complete" refresh by
holding down a modifier key (isn't this also the way IE does it? So the vast
majority of users are trained to already hold down a key to force a full
refresh)."

I disagree with this statement.  I think the vast majority of users doesn't know about shortcuts or modifiers - I think the vast majority of users clicks the little button at the top of the browser window.  Debating whether our behavior or Gecko's behavior for a "normal refresh" is one thing, but claiming that the "vast majority of users" are trained to hold a modifier when they refresh for a full reload is wrong.

By knowing to hold a modifier when refreshing, you're pretty much already a power user.  ;)
Comment 5 Dave Hyatt 2007-05-27 23:19:56 PDT
A better argument would be that the full refresh isn't even remotely necessary.
Comment 6 Mark Rowe (bdash) 2007-05-28 00:35:33 PDT
One situation in which the "full refresh" is necessary is when doing web development.  With Gecko you typically have to resort to shift-refreshing to have it pick up changes to CSS and the like.  I can imagine the same situation happening when tweaking cacheable images during web development.  It seems to me that if we change from reloading *everything* to only reloading a subset of the resources, we will need to provide some way to perform a full reload.
Comment 7 Dave Hyatt 2007-05-28 00:59:26 PDT
Agreed.  I think even for developers we have other UI options than a secret modifier key.

Comment 8 Andrew 2007-05-28 03:05:29 PDT
Brady:

I think all I was trying to get across is that a combination of our competitors (IE + Gecko based browsers which have much greater than 90% of the market cornered) already use a refresh method that involves having to hold down a modifier key to force a refresh that doesn't involve the cache. So there is precedent for this behaviour. I still personally think a smoother refresh would be give a better browsing experience to the majority. Anyone who thinks the thought "I wonder if the reason I'm not seeing my CSS changes is due to the browser retrieving from cache" is a power user who will look for a way to force a full refresh.

===============================================================================

Surely most people use the browser to browse sites not to develop sites? Anyone who does develop sites is likely to have come across the Gecko behaviour of needing to hold a modifier key to perform a full refresh (as which web developer wouldn't check their sites compatibility in Firefox/IE?) so I don't think a change in the way Webkit does this will cause much confusion especially if a menu/gui option is added for a full "forced refresh" not involving the cache (as Dave Hyatt mentions).
Comment 9 Alexander Romanovich 2007-05-28 11:10:26 PDT
This is loosely related to this bug that I posted: http://bugs.webkit.org/show_bug.cgi?id=13128
But in general, I really feel the need to +1 this, as it is behavior that has left me frustrated with Safari in specific situations where I just switch to FF.
I don't think it is unreasonable (given the precedent as someone already pointed out) to maybe match Gecko and then put a checkable option in the debug menu to revert to current Safari behavior, where it reloads all subresources every time. That would satisfy developers. At the very least, you could offer the reverse, where power users can prevent the reloading of subresources every time by checking the option. (Though my vote would be the former...)
Comment 10 Andrew 2007-07-25 10:48:52 PDT
I'm bumping this as I don't want it to get lost in the ether.

I really think perceived rendering speed is such an important factor for a rendering engine. Solving this bug would greatly enhance the perceived rendering speed of refreshes (not to mention smoothness etc). It'd be great if this could be assigned.

Thanks.
Comment 11 Andrew 2007-09-10 09:48:33 PDT
I'm not sure whether to open an new bug report or not. Since this seems to have turned into a more general "Webkit refresh/reload" bug. I find this behaviour strange:

1) Load any website that doesn't fit vertically on your monitor (i.e. it creates a vertical scroll bar).

2) Scroll to the bottom of the page

3) Refresh the page

Why does Webkit jump to the top of the page when a refresh is triggered, only to jump to the bottom again once completed? The initial jump to the top is jarring. It would make for a much smoother refresh process if the page position stayed still and simply refreshed "in place". Perhaps this is technically hard to achieve?
Comment 12 David Kilzer (:ddkilzer) 2007-09-10 10:08:41 PDT
(In reply to comment #11)
> 1) Load any website that doesn't fit vertically on your monitor (i.e. it
> creates a vertical scroll bar).
> 
> 2) Scroll to the bottom of the page
> 
> 3) Refresh the page
> 
> Why does Webkit jump to the top of the page when a refresh is triggered, only
> to jump to the bottom again once completed? The initial jump to the top is
> jarring. It would make for a much smoother refresh process if the page position
> stayed still and simply refreshed "in place". Perhaps this is technically hard
> to achieve?

I don't see this when refreshing this bug page using Safari 3 Public Beta v. 3.0.3 (522.12.1) with a local debug build of WebKit r25465 on Mac OS X 10.4.10 (8R218).  Which version(s) of Safari/WebKit have you tested this with?

Also, how are you refreshing the page?  Cmd-R?  Hitting the "reload" button in the browser?  Selecting "Reload Page" from the "View" menu?  Hitting Cmd-L, then hitting Enter?  Note that ONLY the last action will move the page to the top when the page reloads (for me).  (If you think this is a bug, please file a new bug for this issue.)

Did you happen to test using a page with frames?  If so, that may be Bug 10223.
Comment 13 Gavin Sherlock 2007-09-10 12:47:12 PDT
A page where I frequently notice slow refreshes is at:

http://soccernet-akamai.espn.go.com/scoreboard?league=all&cc=5901

which refreshes itself every 45 seconds, so that scores are updated regularly.  None of the subresources really need refreshing, but the page loads slowly, and consumes a lot of CPU every time the page refreshes.  This is particularly noticeable on a slow network.
Comment 14 Andrew 2007-09-10 13:27:24 PDT
Thanks for the replies. Any website does this to me when I refresh after having scrolled to the bottom/middle. Every way I can find to refresh causes this except Cmd-L then enter which obviously leaves the page at the top. I'm on a wireless connection linked to a fast DSL line. According to http://webkit.org/misc/WebKitDetect.html I'm using 523.5. Can anyone else verify this? Just so we all use the same page it definitely happens to me on: http://news.bbc.co.uk/.

If this is network related then I consider it a bug as Webkit should be able to handle this gracefully.

Comment 15 David Kilzer (:ddkilzer) 2007-09-10 22:14:21 PDT
(In reply to comment #14)
> [...] Can anyone else
> verify this? Just so we all use the same page it definitely happens to me on:
> http://news.bbc.co.uk/.

When I reload the page, it does jump to the top initially, but then jumps back down to where I was scrolled to when the page finishes loading.

Comment 16 Mark Rowe (bdash) 2007-09-10 22:34:00 PDT
I'm not sure why you consider showing the top of the page before restoring the scroll position to be incorrect behaviour.  I can reproduce it in both Safari and Camino.  It logically makes sense that the top of the page must be displayed as the position to which we will scroll may still be loading, or yet to be created via JavaScript, etc.

Can you explain a little as to why you view the behaviour as being incorrect?  I also don't think this relates at all to the original bug report, so discussion of this specific issue should be moved to a new bug report.
Comment 17 Andrew 2007-09-11 01:56:22 PDT
ddkilzer: thanks for the confirmation.

bdash: yes both Camino and Webkit do it on that page, but Camino seems to have more intelligent behaviour, for example it doesn't jump on this page:

http://news.bbc.co.uk/1/hi/scotland/edinburgh_and_east/6988616.stm

or this page:

http://bugs.webkit.org/show_bug.cgi?id=13892

etc etc there are plenty more examples. In both the examples above Webkit jumps. Why do I consider it a bug? Because the Gecko behaviour is smoother and less jarring. Instinctively my eyes follow the page as it flicks to the top and the bottom and as I basically have to sit on the Mac all day refreshing around ten websites for my work this can get tiring for the eyes. I'd rather see everything in place update/refresh then be taken to the top of the page and back especially in cases were the page loads in split seconds.

The reason I've put it in this bug report is because this bug seems to have turned into a more general discussion on refresh behaviour and I thought I'd narrow it down to more specific things that could be made into individual bugs (as it seems nothing is happing with this original report even though Hyatt agreed that the Webkit refresh is too slow).
Comment 18 Mark Rowe (bdash) 2007-09-11 02:22:38 PDT
In my testing, Camino *does* jump back to the top of both http://news.bbc.co.uk/1/hi/scotland/edinburgh_and_east/6988616.stm and http://bugs.webkit.org/show_bug.cgi?id=13892 when refreshing.  I'm pretty sure that it's dependent of the timing of layout + painting in relation to the loading of the data for the page.  If the page is first displayed before enough content to reach the old scroll position has been loaded, then you see the page scrolled to the top, and then to the correct position once things are done loading.  It may just be that my network connection has slightly higher latency, so Camino decides to render the partial content when less data has been received.  Either way, as far as I can tell WebKit and Gecko behave very similarly on this point.

As mentioned, restoration of the scroll position is a different issue than the original bug report.  The original bug report addresses what reload means in terms of which resources should be fetched from the network or cache.  I would much prefer that this is split off into a new bug report before it gets too cluttered with information about a different issue.  Putting everything that is in some way related to reloading in this bug would make it nearly impossible to decide when this bug can be marked as resolved.
Comment 19 Maciej Stachowiak 2007-09-11 02:36:25 PDT
Please do not turn this bug into a catchall for all reload issues. If you can cite specific sites where scrolling behavior is bad, or where doing a full reload is unbearably slow, then separate bug reports about those would be more helpful than additional comments in this bug.
Comment 20 Andrew 2007-09-11 02:44:09 PDT
Ok I'm fine with splitting but could it not be that the initial issue I reported in the bug and this new issue are related? The initial bug report was with in relation to what Webkit used from cache/network when refreshing and the speed of this. This new issue therefore could well be related as on the same network a Gecko refresh on the two sites I listed does not jump to the top of the page where as a Webkit one does. If this behavior is caused by the rendering engine not having enough information to render the page in place then this could be caused by Gecko's more advanced/optimised use of cached images(?) perhaps giving it the ability render the reloaded page sooner and not have to jarringly jump.

If that seems likely then these bugs are one and the same issue.
Comment 21 Andrew 2007-09-13 13:43:00 PDT
Any comment? If this isn't a bug it should be discarded, if it is a bug it needs to be assigned etc etc
Comment 22 Mark Rowe (bdash) 2007-09-13 13:59:22 PDT
If you believe the new issue that you raised is a bug, please open a new bug report and provide information about how to reproduce it so it can be handled separately.
Comment 23 Andrew 2007-09-13 15:34:41 PDT
But I want opinions on whether the "new" issue is in fact a manifestation of the original issue, in which case there is no need for a fresh bug report.
Comment 24 Mark Rowe (bdash) 2007-09-13 16:01:54 PDT
As stated in comment 16:
>I also don't think this relates at all to the original bug report, so
> discussion of this specific issue should be moved to a new bug report.

Comment 25 Andrew 2007-09-13 16:36:24 PDT
That comment was made before my comment asking if they were related! I'll imply you don't think so, even though it seems to me they well could be. I'll create a new bug report when I have time.
Comment 26 Andrew 2007-09-18 15:38:52 PDT
Ok so back on topic, I've found a page which displays my problem from the initial bug report very clearly.

http://tinyurl.com/24hl6c

Refresh that page in Gecko and everything reloads very smoothly and in place. Refresh it in the latest nightly (and other versions of Safari) and the page "flashes" a white page and seems to load/draw images again before showing the content. I would advise refreshing a few times to really get an idea of the difference between them. I hope this illustrates the problem clearly and helps this get reduced.
Comment 27 Andrew 2008-06-03 05:37:37 PDT
Hmm, doesn't seem this is getting much attention. My test case above is still valid, and using the very latest webkit nightly it still flashes a white page every time I refresh whereas in Gecko based browsers the page content stays in place and there is no white page flash during a refresh.

I ping the test site above at a steady 170ms if this helps. Perhaps people who can't reproduce this problem have a faster connection than me to the BBC? Any help in reducing this would be greatly appreciated.

Thanks.
Comment 28 Mark Rowe (bdash) 2008-11-13 15:48:13 PST
The main issue deals with a reload of the page refetching resources rather than revalidating cached resources.  That makes it a dupe of bug 17998.

*** This bug has been marked as a duplicate of 17998 ***