Closed Bug 759512 Opened 12 years ago Closed 12 years ago

Implement <select> popups for mozapp

Categories

(Firefox OS Graveyard :: General, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-kilimanjaro:+, blocking-basecamp:+)

RESOLVED WORKSFORME
blocking-kilimanjaro +
blocking-basecamp +

People

(Reporter: cjones, Unassigned)

References

Details

+++ This bug was initially created as a clone of Bug #759511 +++

See bug 617653 for a discussion of the problem space and some possible solutions.  This bug is separate from the mozbrowser implementation because we may want different UI or a different solution.  Hopefully not.
Whiteboard: [b2g:blocking+]
> This bug is separate from the mozbrowser implementation because we may want different UI or a 
> different solution.  Hopefully not.

Indeed.

The solution most consistent with what we've been doing so far is to let the "embedder" handle this.  The embedder gets an event saying "select start".  It draws UI and sends a message back down to the child when the user selects something.

That's consistent with our current approach to HTML5 context menus (bug 756371).

It has the unfortunate side-effect of allowing browsers to implement context menus or <select> differently than the rest of the system.  There's no good reason for this.

I can imagine a system where we send the <select> and HTML5 context menu events only to the top-level embedder.  That would ensure consistent UI.

That's kind of tricky, though, so I'm in favor of using the HTML5 context menu approach for now, and figuring out whether we can enforce consistent UI across all browser apps later.
IMO, this should be handled by the virtual keyboard and AFAIK, Vivien has the same opinion.
(In reply to Mounir Lamouri (:volkmar) (:mounir) from comment #2)
> IMO, this should be handled by the virtual keyboard and AFAIK, Vivien has
> the same opinion.

I even have a patch in bug 757496 and the Gaia UI will be done by Etienne (i have one but it is sucky).
blocking-basecamp: --- → +
blocking-kilimanjaro: --- → +
Whiteboard: [b2g:blocking+]
Since bug 757496 is closed, should this bug be closed too?
Siiiigh kinda.

MozKeyboard needs to move out of b2g.  That work didn't "Implement <select> popups for mozapp", it added another hack to b2g chrome.  But mozapp <select> should now work incidentally in b2g.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.