Closed Bug 198155 Opened 22 years ago Closed 20 years ago

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

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jruderman, Assigned: glazou)

References

(
URL
)

Details

(Whiteboard: midas)

Attachments

(1 file)

Fix for problem
695 bytes, patch
Details | Diff | Splinter Review
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...
Blocks: contenteditable
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 problem — — Splinter 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: 20 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.

Attachment

General

Creator:
Created:
Updated:
Size: