The default bug view has changed. See this FAQ.

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

RESOLVED FIXED

Status

()

Core
Editor
RESOLVED FIXED
14 years ago
3 years ago

People

(Reporter: Jesse Ruderman, Assigned: glazou)

Tracking

(Depends on: 1 bug)

Trunk
x86
All
Points:
---
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking1.8a6 -
blocking1.8b -
blocking1.8b2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: midas, URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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.
(Reporter)

Updated

14 years ago
Whiteboard: midas
(Reporter)

Comment 1

14 years ago
*** Bug 201223 has been marked as a duplicate of this bug. ***

Comment 2

13 years ago
*** Bug 209836 has been marked as a duplicate of this bug. ***

Comment 3

13 years ago
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+

Comment 4

13 years ago
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

Comment 5

13 years ago
is bug 215686 also a dupe?

Comment 6

13 years ago
This is related to:

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

It has to do with editor teardown.

We need jst.

Updated

13 years ago
Depends on: 209020
*** Bug 215686 has been marked as a duplicate of this bug. ***

Comment 8

13 years ago
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).

Updated

13 years ago
OS: Windows XP → All
Depends on: 180211
OS: All → Windows XP
OS -> All.
OS: Windows XP → All
(Assignee)

Comment 10

13 years ago
Blocks 'contenteditable' feature...
Blocks: 237964
(Assignee)

Comment 11

13 years ago
Wow. Is it really **that** simple to fix ??? Hmmm... Investigating...
Looks like a one-liner to me...
(Assignee)

Comment 12

13 years ago
Yay!!! Fix pending.
mkaply: I presume you won't shout too loud if I take the bug ?-)
Assignee: mkaply → daniel

Comment 13

13 years ago
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.
(Assignee)

Comment 14

13 years ago
mkaply: I saw it on aaronlev just an hour ago. Get ready to go to the PostOffice:-)

Comment 15

13 years ago
Created attachment 157075 [details] [diff] [review]
Fix for problem

from glazou

Comment 16

13 years ago
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?
(Assignee)

Comment 18

13 years ago
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.
(Assignee)

Comment 19

13 years ago
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?
(Assignee)

Comment 21

13 years ago
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

Comment 22

13 years ago
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.

Comment 23

13 years ago
(In reply to comment #22)
> I'm not sure we want contenteditable for aviary/1.7.

Why?

Comment 24

13 years ago
btw: when in designmode onclick events still used to work. I guess they should
be disabled as well, right?

Comment 25

13 years ago
(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.
(Assignee)

Comment 26

13 years ago
(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-

Updated

13 years ago
Flags: blocking1.8a6?

Comment 28

12 years ago
glazou: I still have a very cool IBM Mozilla t shirt waiting for you if we can
get a good fix for this :)

Updated

12 years ago
Flags: blocking1.8a6? → blocking1.8a6-

Updated

12 years ago
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
Last Resolved: 12 years ago
Resolution: --- → FIXED

Comment 32

12 years ago
*** Bug 285801 has been marked as a duplicate of this bug. ***

Comment 33

12 years ago
*** Bug 300360 has been marked as a duplicate of this bug. ***

Comment 34

12 years ago
*** 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.