Rewrite HTML form controls using XBL (XBL form controls)

RESOLVED WONTFIX

Status

()

enhancement
P3
normal
RESOLVED WONTFIX
19 years ago
5 years ago

People

(Reporter: andreww, Unassigned)

Tracking

(Blocks 1 bug, {access})

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

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

Attachments

(4 attachments)

Reporter

Description

19 years ago
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

19 years ago
->moz0.8, pending decision to replace current form controls.
Target Milestone: --- → mozilla0.8

Updated

19 years ago
Target Milestone: mozilla0.8 → mozilla0.9

Comment 2

19 years ago
->moz0.9

Comment 3

19 years ago
->mozilla1.0
Target Milestone: mozilla0.9 → mozilla1.0

Updated

19 years ago
Status: NEW → ASSIGNED
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
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.
Keywords: mozilla1.0

Updated

18 years ago
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

Comment 9

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

Comment 10

18 years ago
Fixing this bug would take care of a large number of accessibility problems.
Blocks: 64165

Comment 11

18 years ago
per jesse's last comment, adding access keyword
Keywords: access

Updated

18 years ago
Blocks: xforms

Updated

18 years ago
Target Milestone: mozilla1.1 → mozilla1.0

Comment 12

18 years ago
-> bryner
Assignee: hyatt → bryner
Status: ASSIGNED → NEW
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."
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.9

Comment 14

18 years ago
Does this mean that bug 18895 is 'wontfix'?
QA Contact: jrgm → vladimire

Comment 15

18 years ago
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.

Updated

18 years ago
Blocks: 102472

Comment 16

18 years ago
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....

Comment 18

18 years ago
(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...

Updated

18 years ago
Whiteboard: [Hixie-P5] → [Hixie-P5][wgate]
*** Bug 58317 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
Moving dependencies from duplicate
Blocks: 39573, 74058
Is this work going to get rid of all native scrollbars?

Please?
bryner has promised me that it will. I asked him several times. :-)
Depends on: 123477
Depends on: 123671

Updated

18 years ago
Blocks: 70210

Updated

18 years ago
Blocks: 126551

Comment 23

18 years ago
nsbeta1+
Keywords: nsbeta1+

Comment 24

18 years ago
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

Updated

18 years ago
Blocks: 112978

Updated

18 years ago
Blocks: 122312

Updated

18 years ago
Blocks: 124234

Updated

18 years ago
Blocks: 127724

Comment 26

18 years ago
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.  :)

Comment 28

18 years ago
adding self to cc list
Depends on: 108309
Depends on: 130003

Comment 29

18 years ago
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

18 years ago
Blocks: 92481

Updated

18 years ago
Blocks: 53603

Comment 30

18 years ago
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.

Updated

18 years ago
Attachment #73868 - Attachment mime type: text/plain → image/gif

Comment 32

18 years ago
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

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

Updated

18 years ago
Whiteboard: [Hixie-P5][wgate] → [Hixie-P5][wgate][adt1]

Comment 34

18 years ago
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

Updated

18 years ago
Blocks: 119696

Comment 37

18 years ago
This bug depends on bug 58317, which is marked as a duplicate of ... this bug! 
Removing the strange loop..
No longer depends on: 58317

Updated

18 years ago
No longer blocks: 119696

Comment 38

18 years ago
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]

Updated

18 years ago
No longer blocks: 124234

Comment 40

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

Comment 41

17 years ago
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.
Posted 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.

Comment 46

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

Comment 47

17 years ago
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
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....

Comment 50

17 years ago
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.

Comment 52

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

Updated

17 years ago
Blocks: grouper

Updated

17 years ago
Summary: Rewrite HTML form controls using XBL (XBL form controls) → Rewrite HTML form controls using XBL (XBL form controls) [t2]

Updated

17 years ago
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]

Comment 53

17 years ago
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

Comment 55

17 years ago
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.
Target Milestone: mozilla1.0.1 → Future

Comment 56

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

Comment 57

17 years ago
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.

Comment 59

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

Comment 60

17 years ago
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.

Comment 62

17 years ago
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. ***

Updated

15 years ago
Assignee: bryner → nobody
Severity: normal → enhancement
Status: ASSIGNED → NEW
QA Contact: vladimire → core.layout.form-controls
reso/Wontfix per roc
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WONTFIX

Comment 66

13 years ago
> 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.