Closed Bug 57209 Opened 20 years ago Closed 15 years ago

Rewrite HTML form controls using XBL (XBL form controls)


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






(Reporter: andreww, Unassigned)


(Blocks 1 open bug)


(Keywords: access, Whiteboard: [Hixie-P5] [wgate] [ADT3 RTM] [T2])


(4 files)

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.
Target Milestone: --- → mozilla0.8
Blocks: 66829
Depends on: 58317
Target Milestone: mozilla0.8 → mozilla0.9
Target Milestone: mozilla0.9 → mozilla1.0
Summary: html form widgets should be able to use XBL → Rewrite HTML form controls using XBL
Target Milestone: mozilla1.0 → mozilla1.1
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
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.
Keywords: mozilla1.0
OS: Windows 95 → All
Hardware: PC → All
Component: XBL → HTML Form Controls
Summary: Rewrite HTML form controls using XBL → Rewrite HTML form controls using XBL (XBL form controls)
Whiteboard: [Hixie-P5]
Blocks: 55285
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.
Blocks: 64165
per jesse's last comment, adding access keyword
Keywords: access
Blocks: xforms
Target Milestone: mozilla1.1 → mozilla1.0
-> bryner
Assignee: hyatt → 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."
Target Milestone: mozilla1.0 → mozilla0.9.9
Depends on: 112713, 112715, 112716
Does this mean that bug 18895 is 'wontfix'?
QA Contact: jrgm → vladimire
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.
Blocks: 102472
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 
Whiteboard: [Hixie-P5] → [Hixie-P5][wgate]
*** Bug 58317 has been marked as a duplicate of this bug. ***
Moving dependencies from duplicate
Blocks: 39573, 74058
Is this work going to get rid of all native scrollbars?

bryner has promised me that it will. I asked him several times. :-)
Depends on: 123477
Depends on: 123671
Blocks: 70210
Blocks: 126551
Keywords: nsbeta1+
bug 124569 may be the duplicate
XBL form controls will not be turned on for 0.9.9.  -> 1.0.
Target Milestone: mozilla0.9.9 → mozilla1.0
Depends on: 128687
Depends on: 128749
Depends on: 128774
Blocks: 112978
Blocks: 122312
Blocks: 124234
Blocks: 127724
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 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, 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
Depends on: 108309
Blocks: 62384
Depends on: 130003
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.
Blocks: 92481
Blocks: 53603
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.
Attachment #73868 - Attachment mime type: text/plain → image/gif
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>)
Whiteboard: [Hixie-P5][wgate] → [Hixie-P5][wgate][adt1]
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.
Target Milestone: mozilla1.0 → mozilla1.0.1
Blocks: 119696
This bug depends on bug 58317, which is marked as a duplicate of ... this bug! 
Removing the strange loop..
No longer depends on: 58317
No longer blocks: 119696
At a feature meeting, it was decided that this doesn't need to be nsbeta1+ anymore.
Keywords: nsbeta1+nsbeta1-
Whiteboard: [Hixie-P5][wgate][adt1] → [Hixie-P5][wgate]
Marking Status Whiteboard with [ADT3 RTM]. This should land on the trunk after
we have branched for Mozilla 1.0.
Whiteboard: [Hixie-P5][wgate] → [Hixie-P5] [wgate] [ADT3 RTM]
No longer blocks: 124234
Sorry for the spam, but is this still planned on implementing fully in the near
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.
Attached file 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.
The baseline issue with some XBL forms elements is in bug 130994.
So 130984 should be in the 'depends on' list.
Depends on: 130994
batch: adding topembed per Gecko2 document
Keywords: topembed
Topembed- as this is not blocking a major embedding customer.
Keywords: topembedtopembed-
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

My apologies; I had missed the fact that the "topembed" keyword and the +-
versions were for Netscape embedding releases.  Never mind me. is also an "bottom" psueduo-embedding customer.  FWIW, this is very
much needed for the Uzilla browser (instrumented for usability testing).
Blocks: grouper
Summary: Rewrite HTML form controls using XBL (XBL form controls) → Rewrite HTML form controls using XBL (XBL form controls) [t2]
Summary: Rewrite HTML form controls using XBL (XBL form controls) [t2] → Rewrite HTML form controls using XBL (XBL form controls)
Whiteboard: [Hixie-P5] [wgate] [ADT3 RTM] → [Hixie-P5] [wgate] [ADT3 RTM] [T2]
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.
No longer blocks: xforms
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
Target Milestone: mozilla1.0.1 → Future
How do I enable XBL Form Controls when building Mozilla? Is there a .mozconfig
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
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/ to include the
"resources" dir and then rebuilding from toplevel will give you a build with all
the XBLFC stuff properly exported...  But would be the one
to check with for sure.
*** Bug 223372 has been marked as a duplicate of this bug. ***
Assignee: bryner → nobody
Severity: normal → enhancement
QA Contact: vladimire → core.layout.form-controls
reso/Wontfix per roc
Closed: 15 years ago
Resolution: --- → WONTFIX
> reso/Wontfix per roc

Shouldn't we be removing layout/forms/resources/content from the Mozilla tree then?
You need to log in before you can comment on or make changes to this bug.