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.

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

->moz0.9

->mozilla1.0

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?

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

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...

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

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

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

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

per jesse's last comment, adding access keyword

-> bryner

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."

Does this mean that bug 18895 is 'wontfix'?

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.

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

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

(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...

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

Moving dependencies from duplicate

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

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

nsbeta1+

bug 124569 may be the duplicate

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

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

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. :)

adding self to cc list

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.

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.

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.

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

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.

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).

What roc said.

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

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

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

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

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.)

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.

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.

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

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

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

Is there a public list of entities which considered "top embedding customers"? Note that this is blocking a number of performance and correctness fixes....

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?

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.

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

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

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.

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.

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

Nathan: It's actually a pref, see Comment #17 It's even accessible in the debug pref panel...

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

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

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!?

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.

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

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 bryner@netscape.com would be the one to check with for sure.

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

reso/Wontfix per roc

> reso/Wontfix per roc Shouldn't we be removing layout/forms/resources/content from the Mozilla tree then?