Build id : Mozilla/5.0 (Android;Linux armv7l;rv:8.0a1)Gecko/20110803 Firefox/8.0a1 Fennec/8.0a1 Device: HTC Desire Z OS: Android 2.3.3 Steps to reproduce: 1. Open Fennec App 2. Browse to http://www.w3.org/MarkUp/Test/HTML401/current/tests/17_6_1-BF-01.html 3. Tap on the Combo Box 4. Select a different option from the list 5. Repeat steps 3-4 for a couple of times Expected result: Taping on the Combo box, it will trigger out the list every time. Actual result: After step 5, taping on the Combo Box inside of an IFrame, will not trigger every time the list.
Created attachment 550655 [details] testcase It turns out this happens when the document with the select is embedded with the <object> tag. I don't see it with a regular iframe. The bug occurs when the select is focused. In that case, the select popup helper doesn't appear anymore when tapping on the select. If you remove the focus from the select, then the select popup helper pops up again, when tapping on the select.
Summary: Unable to trigger a list inside of an IFrame → Unable to trigger a list inside of an Object
Version: Firefox 8 → Trunk
Cristian, I think the url mentioned in comment 0 was to be viewed in an object tage, wasn't it?
At step 2 browse to http://www.w3.org/MarkUp/Test/HTML401/current/tests/sec17_6_1-BF-01.html instead of the one mentioned in comment #0. The webpages path look similar, but there are different pages.
As Martijn said in comment 1, while I was looking for the regression range I noticed that the actual layout of the list allows you to select any option from it and after that the combobox is still in focus and if you tap on it while it is in focus the list is not triggered. If you tap somewhere else so it loses focus then you tap on the combobox again it will trigger the list every time. For the old layout of the list that is triggered when you tap on the combobox you had to tap somewhere else in order to dismiss the list that way the focus was lost by the combobox and at the second tap the list was triggered again. Last build where it is with the old layout is: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b13pre) Gecko/20110223 Firefox/4.0b13pre Fennec/4.0b6pre http://hg.mozilla.org/mozilla-central/rev/88752f2b3088 First build where it is with the new layout is: Mozilla /5.0 (Android;Linux armv7l;rv:2.0b13pre) Gecko/20110224 Firefox/4.0b13pre Fennec/4.0b6pre http://hg.mozilla.org/mozilla-central/rev/881f4ab63c31 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=88752f2b3088&tochange=881f4ab63c31
Is the regression range in comment 4 about what this bug is about? I see talk about 'old layout'/'new layout', is that concerning this bug or is that about a different bug?
Created attachment 555362 [details] list layout This is the old layout of the list and since it was changed to the current layout this started happening.
I'm not seeing anything in the regression range that could be responsible for a layout change of the list popup (that is what has changed in that range, is it?), but I might have overlooked something.
Bug 631119, comment 2 mentions: "Safe patch that can fix weird IME bugs on pages with <select>s." So I guess this could very well be a regression from that bug.
Component: General → Widget
Product: Fennec → Core
QA Contact: general → general
Quick note that the bisection comment 4 crosses the mobile-browser merge into mozilla-central, so the earlier changesets in the bisection would have a mismatched gecko and fennec frontend. That said, the range looks plausible. Not sure what's going on here. I would have thought some other part of the code was responsible for focusing the <select>. The code disabled by this patch may have been unintentionally working around another bug (possibly also in PuppetWidget).
This is reproducible also on Native Fennec. Mozilla /5.0 (Android;Linux armv7l;rv:11.0a1) Gecko/20111208 Firefox/11.0a1 Fennec/11.0a1 Device: LG Optimus 2X (Android 2.2)
You need to log in before you can comment on or make changes to this bug.