617653 - Deal with what are currently popup widgets (e.g. for <select>) in widgetless content processes

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect)

Description

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

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

In bug 585799, we just hacked around the platform problem by creating essentially dummy popups, and relied on fennec's form assistant to do the real work.  So, here's the "real bug" for the platform side.

Comments I consider relevant are included below, edited.  I understand the second option of the first comment to be in the same ballpark as the "higher-level API" of the second comment.

(bug 585799 comment 0)
[snip]
I think we have two approaches, roughly speaking.  One is to teach PuppetWidgets about popup widgets, and create popup PuppetWidgets.  This would entail sending the content process's "widget" hierarchy to the chrome process, because chrome would need to know the z-order of fake widgets.

The second is to add a second, non-widget implementation of the <select> frame (or something to that effect).  Then the <select> can have its own layer (or whatever), and we can reuse all the existing cross-process layer machinery and stuff will Just Work.

I personally lean towards the second option.  I'm afraid of PuppetWidgets
turning into a full-fledged widget toolkit, rather than being simple stand-ins
as they are now.[snip]

(bug 585799 comment 2)
The reason we create a popup widget for <select>s is that we want a large
select to be able to extend outside the browser window on desktop Firefox. We
probably don't want to regress that.
[snip]
Beyond that, we probably should create a higher-level API that lets us send the
options and optgroups over to the chrome process and have it implement the
select functionality itself with the real window toolkit. Maybe we can use the
Fennec API everywhere.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

One important question is how much styling of <option> and <optgroup> we want to support. bz's been looking at that in another bug.

Comment 2

[Andrew Overholt [:overholt]]

cjones say no longer a blocker for basecamp or k9o

Comment 3

[Justin Lebar (not reading bugmail)]

(In reply to Andrew Overholt [:overholt] from comment #2)
> cjones say no longer a blocker for basecamp or k9o

Could you please elaborate?  Is the plan to have desktop-style <select> controls on our phone?

Comment 4

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

<select> in b2g is implemented by the nascent IME API.

Comment 5

[Justin Lebar (not reading bugmail)]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #4)
> <select> in b2g is implemented by the nascent IME API.

So then is this wontfix?  Or what advantage would this bug have over the current solution?

Comment 6

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

We care about content processes outside of b2g.  But not to a degree that I expect anyone to start working on this.

Comment 7

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/a57d3b17dcf8

Comment 8

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/a57d3b17dcf8