Closed Bug 198155 Opened 21 years ago Closed 19 years ago

midas html editing mode persists after leaving the page that enabled it

Categories

(Core :: DOM: Editor, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: glazou)

References

()

Details

(Whiteboard: midas)

Attachments

(1 file)

1. Load http://www.squarefree.com/contenteditable.html .
2. Click a personal toolbar link to http://www.google.com/, or click Home.

Result: The bookmark loads correctly, but loads as an editable document.

Expected: The bookmark should load as a non-editable document, like it does in IE.
Whiteboard: midas
*** Bug 201223 has been marked as a duplicate of this bug. ***
*** Bug 209836 has been marked as a duplicate of this bug. ***
We've got at least 3 dupes of this and I just ran across a user who got nailed
by it in the wild.  As more high profile sites start using Midas, this is going
to only get worse. Who can help? 

bug 209836
bug 201223
bug 221172
Assignee: brade → mkaply
Flags: blocking-aviary1.0+
summary was "click bookmark while editing midas document -> loaded document is
editable" and is now "midas html editing mode persists after leaving the page
that enabled it".  Feel free to improve on that for accuracy or searchability.
Summary: click bookmark while editing midas document -> loaded document is editable → midas html editing mode persists after leaving the page that enabled it
is bug 215686 also a dupe?
This is related to:

http://bugzilla.mozilla.org/show_bug.cgi?id=209020

It has to do with editor teardown.

We need jst.
Depends on: 209020
*** Bug 215686 has been marked as a duplicate of this bug. ***
Coupled with bug 180211, this is pretty serious, as it can make the rest of the
browser session unusable and can occur by accident.  A friend of mine found the
problem in the wild at http://philips.electronics.inreview.com/ (admittedly a
spam page).
OS: Windows XP → All
Depends on: 180211
OS: All → Windows XP
OS -> All.
OS: Windows XP → All
Blocks 'contenteditable' feature...
Wow. Is it really **that** simple to fix ??? Hmmm... Investigating...
Looks like a one-liner to me...
Yay!!! Fix pending.
mkaply: I presume you won't shout too loud if I take the bug ?-)
Assignee: mkaply → daniel
glazman: fixing this bug and hopefully the meta refresh bug in the process would
definitely cause an IBM Mozilla t shirt to be sent your way.
mkaply: I saw it on aaronlev just an hour ago. Get ready to go to the PostOffice:-)
Attached patch Fix for problemSplinter Review
from glazou
OK, so with just this fix, clicking on links products blank pages until you
reload. So there is something missing here.
Wow, that seems too simple to be true :-)

Does this fix this problem when midas is used in an [i]frame etc too?
mkaply: I told you on IRC there was something else. See the modifs on
nsHTMLDocument::SetDesignMode and nsEditingSession::EndDocumentLoad

jst: it was that simple... MakeWindowEditable() on the editorDocShell was creating
the editor but was letting mMakeWindowEditable true, so when the editingSession got
a delayed request for creating *again* an editor after each document onload...
The fix only has checks to reset the boolean as soon as the request is consumed and
check if the docShell is already editable or not. And if it is, reuse the editor.
Done... As I told mkaply on IRC, I just came with a fresh eye.
uuuh, sorry for the lame engish, I am exhausted and about to take a nap. I hope it
was understandable.
Ok, that's cool. I'm glad to see there's an easier fix for this than what I came
up with way back when...

Oh, one more thing that came to mind, does JS get re-enabled when loading a new
page with this change too?
jst: excellent question... I am not at the office right now and not in position
to try; mkaply, can you test if you build with my patch for bug 237964 ?
/me goes to zzzZZzzz now
glazman:

I'll try your entire patch.

I'm trying to put together a patch that just fixes the designMode issue that I
can put in 1.7/aviary. I'm not sure we want contenteditable for aviary/1.7.
(In reply to comment #22)
> I'm not sure we want contenteditable for aviary/1.7.

Why?
btw: when in designmode onclick events still used to work. I guess they should
be disabled as well, right?
(In reply to comment #23)
> (In reply to comment #22)
> > I'm not sure we want contenteditable for aviary/1.7.
> 
> Why?

It's a large functional patch that has the potential to destabilize.
(In reply to comment #23)
> (In reply to comment #22)
> > I'm not sure we want contenteditable for aviary/1.7.
> 
> Why?

Because the number of potential side-effects is high, the number of things to
test to make sure there's no side-effect is high too, because it's won't reach
the stability level required for that.
This only affects the root document it seems... if people use IFRAMEs for the
documents then there is no problem. => not a blocker. 
Flags: blocking-aviary1.0+ → blocking-aviary1.0-
Flags: blocking1.8a6?
glazou: I still have a very cool IBM Mozilla t shirt waiting for you if we can
get a good fix for this :)
Flags: blocking1.8a6? → blocking1.8a6-
Flags: blocking1.8b?
Too late for 1.8b1, but I think we should fix this for b2.
Flags: blocking1.8b?
Flags: blocking1.8b2+
Flags: blocking1.8b-
This appears to be fixed by my proposed fix for bug 209020.
Fixed as a result of the fix for bug 209020.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
*** Bug 285801 has been marked as a duplicate of this bug. ***
*** Bug 300360 has been marked as a duplicate of this bug. ***
*** Bug 301019 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.