300411 - designmode remains when going back in history with bfcache enabled with this designmode testcase

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Martijn Wargers (dead)]

See upcoming testcase.
-Make sure you've enabled bfcache on.
-Open testcase
-Go back

Result:
designmode is still on, while it should be off.

Comment 1

[Martijn Wargers (dead)]

Attachment: testcase

Comment 2

[Brian Ryner (not reading)]

Attachment: patch

This is actually a problem with the timing of the STATE_START notification. 
The editor's WebProgressListener expects the old document to still be in the
window at the time the STATE_START notification is received.  To make that be
true for fastback, I changed things around so that we fire STATE_START for the
toplevel load earlier, before we swap out the content viewer.  Subframes get
their STATE_START _after_ we swap out the content viewer, since in a
non-fastback load we would have had to start loading data in order for a
subframe to be constructed.

Comment 3

[Darin Fisher]

Comment on attachment 189086 [details] [diff] [review]
patch

The call BeginRestore on each child docshell seems like it should be moved into
a subroutine.  Otherwise, this looks good.  I might add some documentation
about the new viewer parameter.

r+sr=darin with those tweaks.

Comment 4

[Brian Ryner (not reading)]

Oh, one more thing I'll explain because it might look like a mistake:  I removed
the call to Show() because this happens implicitly as part of Thaw(). 
PresShell::UnsuppressAndInvalidate calls mPresContext->EnsureVisible() which
takes care of it.

Comment 5

[Brian Ryner (not reading)]

Comment on attachment 189086 [details] [diff] [review]
patch

requesting approval. everything here is localized to fastback.

Comment 6

[Brian Ryner (not reading)]

checked in

Comment 7

[Adrian Yee]

I just tested an hourly trunk build
(http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/prometheus-trunk/
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050714 Firefox/1.0+)
and this fix seems a little broken.

Try this:
- open http://forums.mozillazine.org/viewtopic.php?t=292151
- click on the link that links to this bug (#11: 300411) - this opens into a new
window
- click on the test case attachment link
- press back
- designmode is off which is good.  However, now you can't type into the comment
text area.  Also, if you click on the test case attachment link, it actually
opens up on the mozillazine forum window.

Comment 8

[bomfog]

(In reply to comment #7)
> I just tested an hourly trunk build
> (http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/prometheus-trunk/
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b3) Gecko/20050714 Firefox/1.0+)
> and this fix seems a little broken.

Ditto, with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050715
Firefox/1.0+ ID:2005071508

Fresh zip install, clean profile, ext's: DOMi, Reporter, Talkback, Nightly
Tester Tools, winxp pro sp2.

> Try this:
> - open http://forums.mozillazine.org/viewtopic.php?t=292151
> - click on the link that links to this bug (#11: 300411) - this opens into a new
> window

I just opened this bug from the URL bar.

> - click on the test case attachment link
> - press back
> - designmode is off which is good.  However, now you can't type into the
>   comment text area.

Or any other text area on the page.

> Also, if you click on the test case attachment link, it actually
> opens up on the mozillazine forum window.

Don't see this. The second time clicking the test case link, I get a blank page.
 View-source says the source is there, undisplayed.

Re-open or new bug?

HTH, and isn't just spam.

Comment 9

[Martijn Wargers (dead)]

I believe the issues mentioned in comment 7 and comment 8 are basically the
issues left to fix in bug 287707.