501137 - <select> widget needs to be careful not to append to existing content

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[timeless]

Attachment: an instance of this problem as seen on bugzilla

fennec 1.0b2 OS X

steps:
1. load the url
2. click the second select
3. click the first select

actual results:
the contents from the first select are appended to the list shown for the second one

expected results:
dunno

Comment 1

[Mark Finkle (:mfinkle) (use needinfo?)]

So, you clicked the first select (step #3) while the list picker dialog was being displayed?

I guess we should simulate a modal dialog

Comment 2

[Vivien Nicolas (:vingtetun) (:21) - (NOT reading bugmails, needinfo? please)]

Attachment: Dismiss the select on mousedown

I think we should close it as soon as the user go to another place with his mouse/finger (onmousedown). Otherwise this lead to some unexpected behavior as the one described above but also we can do whatever we want in the chrome UI without closing it (go to the right panel, switch tabs, change the current location, open bookmarks, ...)

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 387175 [details] [diff] [review]
Dismiss the select on mousedown

I think we should just make the picker be modal

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: patch - make the selector be modal

This patch makes the selector UI become modal. The user is forced to close the UI via the "done" button. No other interactions with content or chrome are allowed.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 387203 [details] [diff] [review]
patch - make the selector be modal

>diff --git a/chrome/content/browser-ui.js b/chrome/content/browser-ui.js

>+    //let toolbar = document.getElementById("toolbar-main");
>+    //let top = parseInt(toolbar.top) + toolbar.boxObject.height;
>+    //if (top < 0)
>+      //top = 0;

just remove it?

Comment 6

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: patch 2

Removed the commented code, but realized I needed to move the sizing to BrowserUI.sizeControls

Comment 7

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 387232 [details] [diff] [review]
patch 2

good call

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

pushed: https://hg.mozilla.org/mobile-browser/rev/81033ff6a951

Comment 9

[Al Billings [:abillings - ex-MoCo]]

Verified "fixed" in my OS X build from 8/11/2009. It is pretty ugly though.