Ah, good tip!
Now that sure is something that can be worked-around by a macro, at least when reloading again. But of course that's a bug that should really be fixed. Does it still happen in the latest KM1.8/74??
Or another workaround: Instead of clicking the Reload-Button, click the Go-Button. Then the visible URL is opened again.
Little catch: Have my profile set to open typed URLs in a new tab, so a second tab is still opened. (Check setting in F2 / Browsing / Typed URLs)
Or if a site is know as problematic, and works well enough despite blocked JS, add the site to the blocked JS domains?
Oh, seems to be (has been?) a long time mozilla bug, FF had it too:
The problem is caused by document.write not working in FF as the other browsers: in FF it should be used only at load time, not later.
or add document.close() after the doment.write() call.
Can't help thinking now about macro workarounds... e.g. create a little onLoad-macro, that checks the site URL for wyciwyg, and if necessary cuts it and reloads again? Hmm, could work... But of course nothing of the sort can fix the page suddenly going blank while scrolling down, that's real developer stuff. At most a new workaround-macro could automatically block JS for the time of reloading, so that clueless users at least have a chance to see what they miss ;-) Then at the next reload JS would be ON again... talk about confusing users, LOL!
Then again - what if someone is just really using the cache?? Would the macro also have to check the offline+cache settings? Oh well, gets more and more complicated
PS: perhaps add "(wyciwyg)" to thread title?
Edited 7 time(s). Last edit at 01/19/2014 11:38PM by siria.