Closed Bug 659313 Opened 13 years ago Closed 12 years ago

Keyboard events are not fired when 'designMode' property of document set 'on'

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Platform:
x86_64
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 765780

People

(Reporter: mrakesh, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

Rich text editor
1.13 KB, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534.36 (KHTML, like Gecko) Chrome/13.0.767.1 Safari/534.36
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

Keyboard events are not fired when 'designMode' property of document set 'on'. Instead if we use 'contentEditable' property all events are fired

Reproducible: Always

Steps to Reproduce:
1.open the attached document in  Firefox - 4.0.1
2.type some thing in the document body
3.

Actual Results:  
No alert is displayed

Expected Results:  
alert should come on keydown and keyup
Attached file Rich text editor — 
Version: unspecified → 4.0 Branch

        Attachment #534762 -
        Attachment mime type: text/plain → text/html

    
    

    
  
Confirmed against Mozilla/5.0 (Windows NT 5.1; rv:6.0a1) Gecko/20110524 Firefox/6.0a1 ID:20110524030609. Works in GC 13 canary as stated.
Component: General → Editor
Keywords: testcase
Product: Firefox → Core
QA Contact: general → editor
Version: 4.0 Branch → Trunk

    
    

    
  
We don't run js code in designMode.  :(

Boris, do you remember what's stopping us from doing this?  (What I remember is fear of the unknown!)

    
  
Status: UNCONFIRMED → NEW
Ever confirmed: true

    
    

    
  
So we do run JS in the iframe when using <iframe contenteditable="true">?

    
    

    
  
(In reply to comment #4)
> So we do run JS in the iframe when using <iframe contenteditable="true">?

If you mean contenteditable=true on the <body> element in an iframe, then yes.

    
    

    
  
No, I actually meant the other; I thought there was a way to flag on an <iframe> that the document inside should be editable.

So I assume that what's happening here is that editor suppresses scripts on documents when it's editing the whole document, right?  That makes sense for something like composer.  For designMode... I don't know.  It's really weird to have scripts that you're editing running....

    
    

    
  
(In reply to comment #6)
> No, I actually meant the other; I thought there was a way to flag on an
> <iframe> that the document inside should be editable.

The only way to do that is to get your hands on the contentDocument of the iframe somehow.

> So I assume that what's happening here is that editor suppresses scripts on
> documents when it's editing the whole document, right?

Yes.

> That makes sense for
> something like composer.

There is no need for this behavior to be the same on the web and for Composer.

> For designMode... I don't know.  It's really weird to
> have scripts that you're editing running....

But if you set contenteditable on the <body> element, you'll get scripts running.  And that's supposed to be equivalent to setting document.designMode to "on".  I agree that it might be a good idea to disable script execution in a document for other reasons, but I don't think that there is anything specific to designMode documents which mandates them to be treated differently in this regard.

Do you think this is something worth bringing up in a wider audience forum, such as dev.platform (or maybe even the whatwg list)?

    
    

    
  
> There is no need for this behavior to be the same on the web and for Composer.

Indeed.

> Do you think this is something worth bringing up in a wider audience forum

I think so, yes.  What do other browsers do?

    
    

    
  
Safari and IE do not seem to run JS in designMode, and Chrome, Opera and WebKit (standalone) do.

    
    

    
  
Sounds like WebKit used to do what we do now and then changed to the Opera behavior at some point....

Given the IE behavior, I'd bring this up on public-html or whatever w3c list handles this API.

    
  
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: