292890 - Investigate interaction of bfcache/fastback and midas

Status: RESOLVED FIXED

(Core :: DOM: Navigation, defect)

Description

[Boris Zbarsky [:bzbarsky]]

At least two possible issues here:

First, the editing session is torn down on progress listener notifications, and
fastback doesn't restore it.  

So with fastback if a site sets designMode on a document in a frame, then the
frame is navigated to another URL and then the user goes back we will have:

1)  No editor hooked up in the frame.
2)  The document thinking an editor is hooked up.

At this point there is no way to reenable designMode for that document, due to
item 2, even if the site uses the DOMPageRestore event to do so.

Second, editing session teardown messes with things like image animation modes,
script enabling, etc, etc on the document we're leaving.  If fastback also
messes with them, we need to ensure the two run in the right order.

Simplest solution (and possibly most correct) may be to disable presentation
caching for HTML documents that have mEditingIsOn testing true.

Comment 1

[Johnny Stenback (:jst)]

Yeah, I'm all for the simple sollution here, at least until someone has the time
to really dig into the midas code and make it behave better.

Comment 2

[Adrian Yee]

Here's a simple test case of where bfcache breaks designMode:

http://devrandom.com/test/firefox/editor.html

Comment 3

[Brian Ryner (not reading)]

Attachment: patch

This fixes a regression in the simple testcase above from bug 295931.  We need
to unsuppress painting for subframes.

Comment 4

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

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

Assuming you didn't mean to include the nsLayoutAtomList.h change in this
patch, r+sr=dbaron.

Comment 5

[Brendan Eich [:brendan]]

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

a=me assuming dbaron's comment is right.

/be

Comment 6

[Brian Ryner (not reading)]

checked in