Closed Bug 1144069 Opened 10 years ago Closed 7 years ago

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

Categories

(Core :: DOM: Device Interfaces, defect)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
b2g-v2.1 --- affected
b2g-master --- affected

People

(Reporter: tshiroki.moz, Unassigned)

References

Details

Attachments

(1 file)

Attached patch gecko_keyboard_hide.diff (deleted) — Splinter Review
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?
Component: General → Gaia::Keyboard
Help for clarifying the title. Also, I created a simple page to make tests easiler: http://people.mozilla.org/~lchang/designmode.html
Summary: keyboard does not hide → Keyboard isn't hidden by long pressing space key when focusing in an iframe with "designMode=On"
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.
Hi Howie, Since this bug can be reproduced on master branch as well, could we make it public?
Flags: needinfo?(hochang)
Group: panasonic-confidential
Flags: needinfo?(hochang)
Correct the component per the description and the proposed patch.
Component: Gaia::Keyboard → DOM: Device Interfaces
Product: Firefox OS → Core
(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?
Flags: needinfo?(xyuan)
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
Flags: needinfo?(xyuan)
Flags: needinfo?(xyuan)
Assignee: lchang → nobody
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.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: