Open Bug 776631 Opened 12 years ago Updated 3 years ago

Document in design mode loses focus when arrow keys, home, page down, page up and tab are pressed

Categories

(Core :: DOM: Editor, defect, P5)

13 Branch
x86
Linux
defect

Tracking

()

UNCONFIRMED

People

(Reporter: yak, Unassigned)

Details

Attachments

(1 file)

1.00 KB, application/vnd.mozilla.xul+xml
Details
Attached file testcase.xul
User Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
Build ID: 20120607133124

Steps to reproduce:

I designed a XUL window with an HTML editor embedded in an iframe. (see attachment)


Actual results:

Arrow keys, home, end, page up, page down and tab cause the editor lose focus. They do not perform the desired action. Instead, focus jumps to the next sibling element of the iframe. In case of the example, to the textbox.


Expected results:

The keys should have worked as expected.
Component: Untriaged → Editor
Product: Firefox → Core
Is this a regression?
Attachment #645011 - Attachment mime type: application/octet-stream → application/vnd.mozilla.xul+xml
I should note I am using this in a firefox addon and it's no longer supported as remote content.
I've run into this problem myself, and I found that if I replace my <iframe> with <editor> then the cursor keys will work.
After further testing I found that you need to have type="content-primary", so it should something like <editor id="my-editor" type="content-primary" editortype="html" />

But using type="content-primary" creates some other problems.  For example <editor flex="1"> does nto work if the <editor> is enclosed inside a <vbox>.  Another problem is that overflow: auto no longer works.
The solution is actually quite simple.  If I use <iframe type="content"> then there is no problem with the cursor keys.  I changed testcase.xul with the line <iframe id="theframe" src="http://www.google.com" type="content" flex="10"/> and the problem went away.  Note that in order to see the problem the file testcase.xul has to be launched into its own window using window.openDialog("testcase.xul", "_blank", "centerscreen,resizable=yes,dialog=no"), there is no cursor key problem if testcase.xul is opened in a browser tab.
The problem with type="content" solution is this iframe is not running in the chrome security context and many editing interactions are forbidden.

Note : this issue is a regression after XulRunner10.

A possible hack for this issue is to handle yourself all these events and directly call navigation methods on Editor.selectionController.

An other horrible hack in XulRunner is to by-pass Controller/Command framework in chrome/toolkit/content/global/platformHTMLBindings.xml

For example replace in the <binding id="editor"> :
<handler event="keypress" keycode="VK_LEFT" modifiers="accel" command="cmd_moveLeft2"/>
by :
<handler event="keypress" keycode="VK_LEFT" modifiers="accel">event.target.ownerGlobal.realFrameElement.getEditor(event.target.ownerGlobal).selectionController.wordMove(false, false);</handler>

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.