217205 - Midas doesn't accept input after being hidden with display:none

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Vidar S. Ramdal]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030728 Mozilla Firebird/0.6.1

If a Midas widget (or a parent element) is hidden with display:none, and then
shown again using display:block, input is almost impossible.
Sometimes, you can input a single character before the widget loses focus, other
times it does not accept input at all.

Reproducible: Always

Steps to Reproduce:
Using the testcase:
1. Try typing in the widget
2. Click the "hide" link, then the "show" link
3. Try typing again

Actual Results:  
Widghet does not accept input. No javascript error.

Expected Results:  
Input should be accepted

Seeing this on both Mozilla suite and Firebird

Comment 1

[Vidar S. Ramdal]

Attachment: Testcase

See description

Comment 2

[Vidar Haarr (not reading bugmail)]

Confirmed on WinXP SP1 trunk 2004082204.

I get a couple of error messages in the JS console (when testing the attached
testcase):

Error: uncaught exception: [Exception... "Component returned failure code:
0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIDOMNSHTMLDocument.execCommand]" 
nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
http://bugzilla.mozilla.org/attachment.cgi?id=130356&action=view :: Select ::
line 201"  data: no]

(many of that one) and one of this one:

Error: uncaught exception: Permission denied to get property
HTMLDocument.getElementById

Comment 3

[dolphinling]

Confirming on 2003082422 linux

It seems that changing the display value of the IFrame or any of its parents
away from its original causes it to break

Comment 4

[dolphinling]

I see no JS errors resulting from a simple  -- go to page - click hide - click
show - attempt (failed) to type --  only from other things (like attempting
copy/paste)

Comment 5

[Vidar S. Ramdal]

Attachment: As-simple-as-it-gets testcase

A simplified version of the previous testcase

Comment 6

[Craig Saila]

Confirming problem with simple test case (and my own more complex) with
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030827.

My own example (which I'm unable to attach, although I may try to work up a
simplified version) doesn't involve "display" at all -- it is three FIELDSETs
absolutely positioned on top of one another. The editable IFRAME is in the
second FIELDSETs. 

Once the second is brought to the top (changing the z-index via the DOM), the
following error appears when I try to format the IFRAME contents using code
found at: http://devedge.netscape.com/viewsource/2003/midas/01/example2-index.html

Error: uncaught exception: [Exception... "Component returned failure code:
0xc1f30001 (NS_ERROR_NOT_INITIALIZED) [nsIDOMNSHTMLDocument.execCommand]" 
nsresult: "0xc1f30001 (NS_ERROR_NOT_INITIALIZED)"  location: "JS frame ::
file:///C:/Documents%20and%20Settings/csaila/My%20Documents/Scratch/noticeCMS_api.js
:: doRichEditCommand :: line 100"  data: no]

The DevEdge example works fine, and my version worked with the Mozilla 1.5a
revision.

I am also unable to type any new content within the IFRAME, although no error is
generated when I try.

Comment 7

[Vidar S. Ramdal]

I haven't dug into Mozilla source, but could this be a result of Mozilla
disabling "invisible" input controls? It would make sense that an
input[type=text] box should not be allowed to receive input when it is hidden
(either by display: none or by an overlapping element with higher z-index). And
then, input focus is obviously restored when the input[type=text] is brought
back into view. 
Maybe "someone" forgot to reenable input for a Midas widget?

Comment 8

[Vidar S. Ramdal]

Attachment: Working test case

Just discovered that resetting designMode to "on" after uncovering the Midas
widget restores functionality.
Compare this to the previous testcase, and notice the "Show" link.

Comment 9

[Craig Saila]

Resetting designMode to "on" worked in my problem case, too. Suggest marking it
resolved.

Comment 10

[Ere Maijala (slow)]

No, this should not be marked resolved. It's still a bug even if there's a
workaround.

Comment 11

[Ere Maijala (slow)]

*** Bug 232454 has been marked as a duplicate of this bug. ***

Comment 12

[Ere Maijala (slow)]

From what I could see while debugging this, the presshell gets killed when the
container is hidden. When it's shown again the presshell get recreated, but it
doesn't know anything about being editable.

Comment 13

[José Jeria]

Also, 
document.getElementById("editFrame").contentDocument.designMode
still returns "on", even though it lost the designMode.

Comment 14

[José Jeria]

this works fine now after bug 284245 has been fixed, marking so

Comment 15

[:Gavin Sharp [email: [e-mail]]]

*** Bug 299834 has been marked as a duplicate of this bug. ***