Steps to reproduce: 1. Go to www.mozilla.org 2. Switch theme Actual Results: The page is reloaded. Expected Results: The page should be temporary cached, so that Mozilla don't load the page from the server again.

over to skinability.

Looks like *yet another* symptom of bug 40867. I'm seeing this on Windows 2000, build 2001052904

if the page must be reloaded, then it should be reloaded with the LOAD_FROM_CACHE flag, which is what we use when browsing via history. but you will need to take care to make sure that the page's cache key is properly set, or otherwise pages resulting from POST requests will not be reloaded properly. ultimately, this just needs to go through docshell (i would think) with the correct docshell flags whatever they might be.

a fix for this bug might depend on bug 40867, unless there is a way to switch skins without reloading pages too.

might be dup of bug 75091 ?

I was talking to Asa about this problem, and he said that we used to not reload the page at all (not even from the cache).

See also bug 43350, composer (or message compose) data is blown away on theme switch.

'Apply Theme' 'Theme changes will take effect when you restart Mozilla' Come on, that's a rather half-baked solution, isn't it? I agree that it does solve the problem for the moment (while bug 40867 still blocks it), but I'd much rather be able to switch skins without restarting (and losing all the pages I was looking at).

Marking NEW.

The page shouldn't reload -- we shouldn't lose current position, we shouldn't lose the current selection, we shouldn't reset any running scripts, nothing. The browser frame should be left alone while the outer stuff (the chrome) is reframed. This is a general bug -- reframing a document shouldn't affect any subdocuments. I filed this issue in bug 94623; marking dependencies.

*** Bug 94858 has been marked as a duplicate of this bug. ***

cc self

This if fixed, thanks to hyatt.

Verified on windows and linux(2002-01-29-06-trunk)