[Android] selected attribute on HTML <option> doesn't work when <select> size is >1 (listbox select)
Categories
(Core :: Layout, defect, P1)
Tracking
()
People
(Reporter: siwon_97, Assigned: emilio)
Details
(Whiteboard: [layout:triage-discuss] [geckoview-])
Attachments
(10 files)
|
5.24 KB,
image/png
|
Details | |
|
341 bytes,
text/html
|
Details | |
|
50.00 KB,
image/png
|
Details | |
|
430 bytes,
text/html
|
Details | |
|
151.91 KB,
image/png
|
Details | |
|
39.38 KB,
image/png
|
Details | |
|
2.08 KB,
text/html
|
Details | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review | |
|
47 bytes,
text/x-phabricator-request
|
Details | Review |
Example of the display in both case.png
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Steps to reproduce:
Try the following HTML page on Fennec 68.1
<!DOCTYPE html>
<html>
<body>
<select size="3">
<option value="1">A</option>
<option value="2" selected>B</option>
<option value="3">C</option>
</select>
<select size="2">
<option value="4">D</option>
<option value="5" selected>E</option>
</select>
</body>
</html>
Actual results:
Nothing is selected. When I select something in the first menu, it is highlighted. If then I press somewhere else on the screen, the highlighting dissapear, making it impossible to know what is actually selected.
Expected results:
The B and E should be in evidence, as they are selected, as on Firefox's Windows version. When selecting other items on the drop out menus, it should leave the new selection selected.
|
||
Comment 1•5 years ago
|
||
Hello,
I have managed to reproduce your issue on the latest builds: 71.0a1 (2019-09-8), 70.0b5 and Release 68.1 with a Samsung Galaxy S8+ (Android 8.0). The issue does not occur on Android Chrome or Firefox Windows.
I will mark the issue as New.
|
||
Comment 2•5 years ago
|
||
(In reply to Laurentiu Apahidean from comment #1)
Hello,
I have managed to reproduce your issue on the latest builds: 71.0a1 (2019-09-8), 70.0b5 and Release 68.1 with a Samsung Galaxy S8+ (Android 8.0). The issue does not occur on Android Chrome or Firefox Windows.
I will mark the issue as New.
Laurentiu, does this reproduce even if on Fenix?
|
|
||
Comment 3•5 years ago
|
||
(In reply to Makoto Kato [:m_kato] from comment #2)
Laurentiu, does this reproduce even if on Fenix?
I have retested it on Firefox Preview 1.4.0 (Build #12481824) 9/5 using a Samsung Galaxy S8+ (Android 8.0.0) and the issue is reproducible.
|
||
Comment 4•5 years ago
|
||
|
||
Updated•5 years ago
|
|
||
Comment 5•5 years ago
|
||
I can reproduce the issue in Firefox Reality Using GeckoView 71.
|
|
||
Updated•5 years ago
|
|
||
Comment 6•5 years ago
|
||
Sending to [layout:triage-discuss]. Is this a Gecko Layout bug or an Android Widget style issue?
Not sure where the bug is, but this is pretty basic functionality to be broken on Android.
The behavior I see is different, but equally bad. Things improve if I tap on the control.
|
||
Comment 9•5 years ago
|
||
This is likely a bug in the Android form-control implementation, which belongs under Widget:Android I think.
snorp, I know you've done some work in that area - do you know who'd be best to poke about this these days?
|
|
||
Comment 10•5 years ago
|
||
|
|
||
Comment 11•5 years ago
|
||
For the record, my Firefox Preview (on play store beta-channel) on Pixel3/AndroidQ matches dbaron's rendering in comment 8, with both testcases. (testcase 2 has a different border/background, but the highlighted entries are still entirely missing as shown in dbaron's screenshot.)
|
Reporter | |
Comment 12•5 years ago
|
||
Here are the screens of Firefox preview 2.0.0 on my Fairphone2 with Android 7.1.2.
After testing testcase2, it seems that testcase1 is trying to put a white highlighting on a white background. Same behaviour on Fennec 68.1.1
This is quite different from comment 8's image.
|
|
Reporter | |
Comment 13•5 years ago
|
||
This bug seems to have various effects depending mainly on which version of Android the user is using.
Before having a Fairphone 2 that use Android 7.1.2, I had an Acer using Android 6.X and I did not have the bug. By retrying it with Fennec 68.1.1 on another Android 6.0 device (Emporia S2), I also do not notice any bug (see attached picture).
(In reply to Daniel Holbert [:dholbert] from comment #9)
This is likely a bug in the Android form-control implementation, which belongs under Widget:Android I think.
snorp, I know you've done some work in that area - do you know who'd be best to poke about this these days?
Most of the people who worked on that were Fennec frontend folks. I think the GeckoView team would like the Layout team to own this going forward if that's possible. My guess is that we have a lot of cruft here from early mobile web days that could be removed?
|
|
||
Comment 15•5 years ago
|
||
Adding [geckoview-] whiteboard tag because the GeckoView team is not responsible for this widget behavior.
|
|
||
Comment 16•4 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #11)
For the record, my Firefox Preview (on play store beta-channel) on Pixel3/AndroidQ matches dbaron's rendering in comment 8, with both testcases. (testcase 2 has a different border/background, but the highlighted entries are still entirely missing as shown in dbaron's screenshot.)
~good news: I retested this, on the same device with the same Android version (android Q aka 10) as I was using in comment 11, and I'm not seeing any entirely-unpainted entries now. Hooray! (Not sure if that's from a firefox change vs. an Android update. shrug)
The two testcases look exactly like the screenshot in comment 12 to me now (though it's worth noting that the dotted-border and yellow background around/behind "B" only show up when I literally tap that element to focus it, as noted in that screenshot's descriptive text).
So: this is still broken, but it's not broken as badly as I'd described in comment 11. Basically, you can't tell which option is selected, with a default-styled <select multi>, so this is still problematic.
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 17•4 years ago
|
||
These are all the colors that the android theme supports. Some of them are defined via prefs, others via some somewhat dubious native code.
|
|
Assignee | |
Updated•4 years ago
|
|
|
Assignee | |
Comment 18•4 years ago
|
||
This doesn't change behavior, just makes the color return what we set right now
via prefs in mobile/android/app/mobile.js.
|
||
Updated•4 years ago
|
|
|
Assignee | |
Comment 19•4 years ago
|
||
Depends on D69938
|
|
Assignee | |
Comment 20•4 years ago
|
||
They're supposed to be the same, though right now they are black on white
because only highlight was overridden via prefs.
I'll fix the bugs I found yesterday in a separate bug.
Depends on D69939
|
|
Assignee | |
Updated•4 years ago
|
|
||
Comment 21•4 years ago
|
||
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/fdb5b47d9c64 Hardcode some system colors. r=snorp https://hg.mozilla.org/integration/autoland/rev/687759fd8798 Stop overriding system colors via prefs. r=snorp https://hg.mozilla.org/integration/autoland/rev/a45871505bd4 Make the cell-highlight colors the same as highlight. r=snorp
|
|
||
Comment 22•4 years ago
|
||
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/251da9f03797 Minor cleanup, and fixup field to be white again.
|
||
Comment 23•4 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/fdb5b47d9c64
https://hg.mozilla.org/mozilla-central/rev/687759fd8798
https://hg.mozilla.org/mozilla-central/rev/a45871505bd4
https://hg.mozilla.org/mozilla-central/rev/251da9f03797
|
||
Updated•4 years ago
|
Description
•