1144069 - Keyboard isn't hidden by long pressing space key when focusing in an iframe with "designMode=On"

Status: RESOLVED INCOMPLETE

(Core :: DOM: Device Interfaces, defect)

Description

[tshiroki.moz]

Attachment: gecko_keyboard_hide.diff

Keyboard does not hide in page using Rich Text.(designMode = ON)
ex, http://www.sepia.dti.ne.jp/bluesky/program/rich_editor2.html
This problem is same FxOS smartphone. (Hide by long press space key).

I tried to fix the problem by reference this URL.  (Attachment file)
https://searchcode.com/codesearch/view/26723440/

However, I do not know how correct this.
Do you have a better how to fix?

Comment 1

[Luke Chang [:lchang] (inactive)]

Help for clarifying the title.

Also, I created a simple page to make tests easiler: http://people.mozilla.org/~lchang/designmode.html

Comment 2

[Luke Chang [:lchang] (inactive)]

The patch attached in comment 0 was added by bug 823645 once but removed by bug 811177 then.


Hi Xulei,

Since you have reviewed the patch in bug 811177, could you please help to take a look? Thanks a lot.

Comment 3

[Luke Chang [:lchang] (inactive)]

Hi Howie,

Since this bug can be reproduced on master branch as well, could we make it public?

Comment 4

[Rudy Lu [:rudyl] (inactive after 2015/7/3)]

Correct the component per the description and the proposed patch.

Comment 5

[Yuan Xulei [:yxl] (Leave from May 18)]

(In reply to Luke Chang [:lchang] from comment #2)
> The patch attached in comment 0 was added by bug 823645 once but removed by
> bug 811177 then.
Great! It is really challenging for you to find the cause of the this bug from a bunch of old bugs.

It is almost right. Bug 811177 didn't remove the patch of bug 823645, but rather refactored it. However the code after refactoring is not strickly indentical to the original one.

When focusing on an iframe inside a document with "designMode=On", after refactoring of bug 811177, we set the focused element to `document.body` instead of `document` and fails to check the `designMode` property from the focused element. If we set the focused element back to `document` instead of `document.body`, we could fix this.

@Luke, would you like to fix this gecko bug？

Comment 6

[Luke Chang [:lchang] (inactive)]

Hi Xulei,

It can't be fixed by setting focused element back to "document" in line [1]. I also noticed that the "isContentEditable" function has already checked `element.ownerDocument.designMode == "on"` in line [2] so I guess it shouldn't fail even the focused element is "document.body".

After some tests, I found that this bug happens because currently the "blur" event isn't triggered when we long press the space bar. I compared the current behavior with the former one and learned that the major difference between them maybe happens in "getTopLevelEditable" [3]. With the patch in comment 0, "getTopLevelEditable" will cause to return "HTMLIFrameElement" instead of "HTMLBodyElement" but I haven't figured out the relationship between the "blur" event and "HTMLIFrameElement". What do you think?

[1] https://dxr.mozilla.org/mozilla-central/source/dom/inputmethod/forms.js#373
[2] https://dxr.mozilla.org/mozilla-central/source/dom/inputmethod/forms.js#814
[3] https://dxr.mozilla.org/mozilla-central/source/dom/inputmethod/forms.js#727

Comment 7

[Kyle Machulis [:qdot] [:kmachulis] (INACTIVE)]

Cleaning up Device Interfaces component, and mass-marking old FxOS bugs as incomplete.

If any of these bugs are still valid, please let me know.