57209 - Rewrite HTML form controls using XBL (XBL form controls)

Status: RESOLVED WONTFIX

(Core :: Layout: Form Controls, enhancement, P3)

Description

[andreww]

Many folks want to be able to have the form widgets they see in html pages 
match the skin that the browser has currently set.  This bug encompasses 
enabling html form widgets to be (optionally) definable via XBL.

Comment 1

[Peter Trudelle]

->moz0.8, pending decision to replace current form controls.

Comment 2

[Peter Trudelle]

->moz0.9

Comment 3

[Peter Trudelle]

->mozilla1.0

Comment 4

[Ben Bucksch (:BenB)]

hyatt, I'm a bit confused. Summary has been changed from "html form widgets
should be able to use XBL" to "Rewrite HTML form controls using XBL". There's
also "Use XBL-ified widgets of current theme for HTML form controls" (bug 58317).

Isn't there a difference between "can do" and "will do myself"? Is the "can do"
already done, and you reuse the bug to track the next step now?

Why this matters: If I wanted to make the HTML renderer use native widgets, I'd
care about the old summary, but not the new one, right? Or did I misunderstand
something?

Comment 5

[Ben Bucksch (:BenB)]

Or is there another bug which tracks my ability to hack the engine to use native
widgets? (not native-looking widgets)

Comment 6

[Hixie (not reading bugmail)]

BenB: To use native widgets for form controls you will probably have to use XBL
anyway -- you would probably use plugins or some such in the generated content 
part, and talk to them from the XBL <implementation>. Assuming you have working
widget plugins, it should be relatively easy. The hard part is writing those
plugins, of course...

Comment 7

[Ben Bucksch (:BenB)]

Yes, I remember the discussion on .seamonkey. But is that possible today? If
not, which bug tracks that ability?

Comment 8

[Hixie (not reading bugmail)]

BenB: The only thing blocking you from doing that is this bug.

Comment 9

[basic]

does this bug really depends on bug 58317 ? Or is it the other way round?

Comment 10

[Jesse Ruderman]

Fixing this bug would take care of a large number of accessibility problems.

Comment 11

[Chad Austin]

per jesse's last comment, adding access keyword

Comment 12

[Peter Trudelle]

-> bryner

Comment 13

[sairuh (rarely reading bugmail)]

jesse's comments from bug 57192:
"By the way, bug 57209 (use xbl controls for html forms) would make 64157 apply
to both xul and html, possibly regressing bug 57192."

Comment 14

[Ari]

Does this mean that bug 18895 is 'wontfix'?

Comment 15

[Tony Tovar]

If this bug takes priority over 18895, please make sure to test that it 
fixes/unblocks bugs 24210, 33732 (especially!), 62278 and 77421.

This may also mean that those bug numbers need to be added to the "blocks" list 
(I'm not the one to do it), and that all the people who've voted for those 
blocked bugs should add/switch their votes to this bug.

Comment 16

[Aaron Leventhal]

Brian, if you find the all.js pref that turns these widgets on can you put it in
this bug for us?

Comment 17

[Boris Zbarsky [:bzbarsky]]

nglayout.debug.enable_xbl_forms should do it....

Comment 18

[Tony Tovar]

(Follow-up to my Dec. '01 comment)

Does this bug supercede bug 18895?  Should it be marked as blocking bug 33732?

Really, as 1.0 approachs, I can't believe bug 33732 isn't getting more 
attention...

Comment 19

[Brian Ryner (not reading)]

*** Bug 58317 has been marked as a duplicate of this bug. ***

Comment 20

[Daniel Bratell]

Moving dependencies from duplicate

Comment 21

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

Is this work going to get rid of all native scrollbars?

Please?

Comment 22

[Hixie (not reading bugmail)]

bryner has promised me that it will. I asked him several times. :-)

Comment 23

[Peter Trudelle]

nsbeta1+

Comment 24

[Jerry]

bug 124569 may be the duplicate

Comment 25

[Brian Ryner (not reading)]

XBL form controls will not be turned on for 0.9.9.  -> 1.0.

Comment 26

[David Illsley]

Dunno if this is appropriate, the XBL turn on pref used to say don't file bugs.
Currently it doesn't say anything so I'll not file another bug unless asked. If
you turn on XBL form controls:

1. They look really really nice
2. Visit slashdot.org and notice that their navbar (OSDN) including form spreads
out onto multiple lines. Last time I used it without XBL controls enabled it was
all on one line, and a glance at the HTML suggests it should all be on one line.
Looks like there is a problem with the impl. of the XBL controls.

Sorry to all not interested in the impl for the spam.

David

Comment 27

[Boris Zbarsky [:bzbarsky]]

David, the controls are definitely at a point where bugs can be filed (on
bryner).  Please check for dups as usual, though -- bryner has been busy filing
such bugs himself.  :)

Comment 28

[djoham]

adding self to cc list

Comment 29

[Bernd]

bryner: please make these controls working in viewer. If you don't do that the
xbl form controls are excluded from the layout regression tests. I especially
hooked up formctls to the layout regression tests. Its just your decision
whether you need some debug support or not.

Comment 30

[Alfred Kayser]

Updated LittleMozilla to support XBL-based forms, and looks good,
for the most part. However: radio buttons are wierd (bug 130003),
and the 'select-dropdown' is baselined wrongly in forms.css.
I'll attach capture of slashdot's header.

Comment 31

[Alfred Kayser]

Attachment: Forms in slashdot's header

Comment 32

[James Lariviere]

I've been meaning to file that one for a few days but figured it had already 
been filed (I see no dupes). So Alfred, I just filed bug 130617 for the xbl 
select baseline issue.

Comment 33

[Ari]

Is there any plan to make form text frames (<input type=text> and <textarea>)
skinable?

Comment 34

[Adam D. Moss]

Are XBL widgets going to be 'on' for 1.0?  They're lovely
and good an' all, but this seems like a pretty major
switch to be flicking at the 11th hour.

Comment 35

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

I think the current plan is to not turn them on for 1.0, but they might get
turned on in the 1.0 branch at some point (1.0.x).

Comment 36

[Brian Ryner (not reading)]

What roc said.

Comment 37

[Diego Biurrun]

This bug depends on bug 58317, which is marked as a duplicate of ... this bug! 
Removing the strange loop..

Comment 38

[scottputterman]

At a feature meeting, it was decided that this doesn't need to be nsbeta1+ anymore.

Comment 39

[Jaime Rodriguez, Jr.]

Marking Status Whiteboard with [ADT3 RTM]. This should land on the trunk after
we have branched for Mozilla 1.0.

Comment 40

[Adam Tomlinson]

Sorry for the spam, but is this still planned on implementing fully in the near
future?

Comment 41

[Adam D. Moss]

FWIW I've been running with this enabled for quite
a while and it seems to be looking good.  (My only
complaint is that text-box text seems to inherit the
current text colour but not the current backgroud colour.)

Comment 42

[John Keiser (jkeiser)]

On the issue of XBL bloat.

I did some bloat tests on a Linux machine recently and came up with surprisingly
consistent numbers (generally the numbers are accurate to within ~50K).  I
loaded these tests off of the hard drive to avoid inconsistencies from the
network.  I did two tests: (1) 9 of each form control, and (2) 1 of each form
control, with a control empty page containing just a form.  The testcases are
attached (to do individual controls you just remove the ones you don't want to
mess with).

In short, XBL form controls seems to add around a total of 500K of size
statically, and in general takes significantly more memory per control as well
(I count ~10K *extra* per control).  The static bloat is not bad; given that
we'd remove the existing form controls if we landed XBLFC it probably evens out.
 but the per-control numbers are extremely disturbing.

I will post the result numbers and testcases shortly.

Comment 43

[John Keiser (jkeiser)]

Attachment: 9-form-control test

Comment 44

[John Keiser (jkeiser)]

Attachment: 1-form-control test

Comment 45

[John Keiser (jkeiser)]

Attachment: XBL Bloat Numbers

This is numbers from running the above tests on Harish's Linux machine.  To get
individual form control types I just deleted all other form controls from the
testcase.  I stopped and restarted the browser each time, pointed directly at
the testcase.  The numbers did not generally fluctuate (once or twice I would
get a sudden jump of 100K but many subsequent runs averaged out).  I did more
runs on the "all form controls" and "no controls" cases.

Comment 46

[Alfred Kayser]

The baseline issue with some XBL forms elements is in bug 130994.
So 130984 should be in the 'depends on' list.

Comment 47

[Marek Z. Jeziorek]

batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html

Comment 48

[Jaime Rodriguez, Jr.]

Topembed- as this is not blocking a major embedding customer.

Comment 49

[Boris Zbarsky [:bzbarsky]]

Is there a public list of entities which considered "top embedding customers"?

Note that this is blocking a number of performance and correctness fixes....

Comment 50

[saari (gone)]

Top embedding customers aside for a moment, xbl form controls has more work that
needs to be done on it in terms of bugs and bloat, and we don't really have head
count or time to do it right now, and it isn't a strict requirement for those
embedding customers.

As for who the top embedding customers are, they're mostly internal customers so
we can't really talk about them. I'm guessing Red Hat would be the most
interested in this, correct?

Comment 51

[Boris Zbarsky [:bzbarsky]]

I agree that there's a lot more work that would need to happen.  No arguments
there...

My apologies; I had missed the fact that the "topembed" keyword and the +-
versions were for Netscape embedding releases.  Never mind me.

Comment 52

[Andy Edmonds]

Uzilla.net is also an "bottom" psueduo-embedding customer.  FWIW, this is very
much needed for the Uzilla browser (instrumented for usability testing).

Comment 53

[Andrew Hagen]

This is blocking XForms, which is needed for corporate customers. Nsenterpise.
Target Milestone needs updating. Nominating for 1.3.

Comment 54

[John Keiser (jkeiser)]

AFAIK this is *not* blocking XForms--and I'm the one planning to implement it. 
If you have some info on why XForms cannot be done by using XBL to vector to our
existing controls, I'd really like to hear it as it will affect the
implementation plan drastically.

That said, I'd still like to see this sometime, it's just a matter of
investigating where the heck that bloat came from and killing it--it sounds to
me like a fundamental XBL issue.

Comment 55

[Paul]

The target milestone for this bug is set at mozilla1.0.1, which, IIRC, was
released a while ago.  Can this be updated to reflect a real target?  I would
like to know, as certain bugs for the BeOS port can be dropped, once this is
applied.

Comment 56

[Nathan Hamblen]

How do I enable XBL Form Controls when building Mozilla? Is there a .mozconfig
option?

Comment 57

[Robert Kaiser]

Nathan:
It's actually a pref, see Comment #17

It's even accessible in the debug pref panel...

Comment 58

[Christian :Biesinger (don't email me, ping me on IRC)]

um, kairo, that pref does not currently work because the files necessary for it
are not packaged with mozilla.

Comment 59

[Robert Kaiser]

um, biesi, if that's right, then it's a bug that it shows up in the debug pref
panel...

Comment 60

[Nathan Hamblen]

Yes, it's a bug that it shows up in debug prefs. Select it restart; you won't be
able to use forms at all. Anyway, back to my question...

Is there any way to enable XBL form controls when building mozilla? Or are we
doomed to ugly widgets FOREVAAAAH!?

Comment 61

[Boris Zbarsky [:bzbarsky]]

Nathan, you have to either edit makefiles or run make in the relevant dirs (the
ones that contain the XBL and CSS for the form controls) by hand to get those
files exported to dist/ properly.

Comment 62

[Dan Hale]

Is there a HOWTO that would help with this, Boris? I'm willing to learn, but IANAP.

Comment 63

[Boris Zbarsky [:bzbarsky]]

Dan, I _think_ just editing layout/html/forms/Makefile.in to include the
"resources" dir and then rebuilding from toplevel will give you a build with all
the XBLFC stuff properly exported...  But [e-mail] would be the one
to check with for sure.

Comment 64

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 223372 has been marked as a duplicate of this bug. ***

Comment 65

[Justin Wood (:Callek)]

reso/Wontfix per roc

Comment 66

[Aaron Leventhal]

> reso/Wontfix per roc

Shouldn't we be removing layout/forms/resources/content from the Mozilla tree then?