1. goto http://people.mozilla.com/~nhirata/html_tp/bug573447.htm 2. click in the iframe in the middle Expected: VKB appears Actual: nothing happens. Testday build
Can't type in it at all.
Whiteboard: [testday-20111111] → [testday-20111111], [VKB]
Regression with the latest pan/zoom layers implementation - it used to work before. Patrick, do you have a clue why this has broken?
(In reply to Alex Pakhotin (:alexp) from comment #2) > Regression with the latest pan/zoom layers implementation - it used to work > before. > Patrick, do you have a clue why this has broken? Not off the top of my head. I'll need to investigate.
This issue and bug 701706 are caused by the new check in the BrowserEventHandler.handleEvent() function: http://hg.mozilla.org/projects/birch/file/04b6e59f4e82/mobile/android/chrome/content/browser.js#l1300 It calls _elementReceivesInput() function, which returns false for the editable iframe element, and for the area outside of the edit boxes, so the "mousedown" event is not handled properly. I'm not sure at the moment how to fix it, but some better check is definitely needed there. Actually, I don't really see any issues if _elementReceivesInput() just always returns true, or its call (with aEvent.preventDefault) is just removed. What kind of selection is it supposed to stop?
Created attachment 575611 [details] [diff] [review] Fix Added a check for designMode=="on".
Assignee: nobody → alexp
Status: NEW → ASSIGNED
Attachment #575611 - Flags: review?(mark.finkle)
Comment on attachment 575611 [details] [diff] [review] Fix This is good, but you might be missing a few cases that we had covered in XUL Fennec. See if you can add any more checks from here: http://mxr.mozilla.org/mozilla-central/source/mobile/xul/chrome/0
(In reply to Mark Finkle (:mfinkle) from comment #6) > > This is good, but you might be missing a few cases that we had covered in > XUL Fennec. See if you can add any more checks from here: > http://mxr.mozilla.org/mozilla-central/source/mobile/xul/chrome/content/ > forms.js#536 Yes, I checked that, just wasn't sure if the other cases aren't already covered by the current implementation - it's a bit different approach used here in the browser.js compared to forms.js. But probably I'll just copy the _isEditable function from the forms and call it instead of my one additional check.
Created attachment 576071 [details] [diff] [review] Fix v2 Using the _isEditable() function from the forms.js to have a more thorough check for an editable element. Though it fixes the bug, the workaround patch from bug 701706 would make the _elementReceivesInput() function obsolete. I guess we have to decide, which way to choose to fix these regressions.
Comment on attachment 576071 [details] [diff] [review] Fix v2 This will have to do for know. Fixing these issues by better controlling the mouse events is a longer term solution.
Attachment #576071 - Flags: review?(mark.finkle) → review+
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Samsung Nexus S (Android 2.3.6) 20111122060933 http://hg.mozilla.org/projects/birch/rev/c26b7a14e5bd
Status: RESOLVED → VERIFIED
Actually, I can still reproduce this bug in current trunk build, I guess it might be a new regression, so I filed bug 711496 for it.
You need to log in before you can comment on or make changes to this bug.