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

RESOLVED WORKSFORME

Status

()

defect
RESOLVED WORKSFORME
9 years ago
3 years ago

People

(Reporter: cjones, Unassigned)

Tracking

unspecified
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

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

Details

+++ 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.
One important question is how much styling of <option> and <optgroup> we want to support. bz's been looking at that in another bug.
tracking-fennec: 2.0b1+ → ---

Updated

7 years ago
blocking-basecamp: --- → ?
blocking-kilimanjaro: --- → ?
cjones say no longer a blocker for basecamp or k9o
blocking-basecamp: ? → -
blocking-kilimanjaro: ? → -
(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?
<select> in b2g is implemented by the nascent IME API.
(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?
We care about content processes outside of b2g.  But not to a degree that I expect anyone to start working on this.

Updated

3 years ago
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.