Closed
Bug 57209
Opened 24 years ago
Closed 18 years ago
Rewrite HTML form controls using XBL (XBL form controls)
Categories
(Core :: Layout: Form Controls, enhancement, P3)
Core
Layout: Form Controls
Tracking
()
RESOLVED
WONTFIX
Future
People
(Reporter: andreww, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: access, Whiteboard: [Hixie-P5] [wgate] [ADT3 RTM] [T2])
Attachments
(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.
Comment 1•24 years ago
|
||
->moz0.8, pending decision to replace current form controls.
Target Milestone: --- → mozilla0.8
Updated•24 years ago
|
Target Milestone: mozilla0.8 → mozilla0.9
Comment 2•24 years ago
|
||
->moz0.9
Updated•24 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
Comment 4•24 years ago
|
||
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•24 years ago
|
||
Or is there another bug which tracks my ability to hack the engine to use native
widgets? (not native-looking widgets)
Comment 6•24 years ago
|
||
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•24 years ago
|
||
Yes, I remember the discussion on .seamonkey. But is that possible today? If
not, which bug tracks that ability?
Comment 8•24 years ago
|
||
BenB: The only thing blocking you from doing that is this bug.
Keywords: mozilla1.0
Updated•24 years ago
|
OS: Windows 95 → All
Hardware: PC → All
Updated•24 years ago
|
Component: XBL → HTML Form Controls
Summary: Rewrite HTML form controls using XBL → Rewrite HTML form controls using XBL (XBL form controls)
Whiteboard: [Hixie-P5]
does this bug really depends on bug 58317 ? Or is it the other way round?
Comment 10•23 years ago
|
||
Fixing this bug would take care of a large number of accessibility problems.
Blocks: 64165
Updated•23 years ago
|
Target Milestone: mozilla1.1 → mozilla1.0
Comment 13•23 years ago
|
||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.9
Updated•23 years ago
|
Comment 14•23 years ago
|
||
Does this mean that bug 18895 is 'wontfix'?
Updated•23 years ago
|
QA Contact: jrgm → vladimire
Comment 15•23 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.
Comment 16•23 years ago
|
||
Brian, if you find the all.js pref that turns these widgets on can you put it in
this bug for us?
Comment 17•23 years ago
|
||
nglayout.debug.enable_xbl_forms should do it....
Comment 18•23 years ago
|
||
Comment 19•23 years ago
|
||
*** Bug 58317 has been marked as a duplicate of this bug. ***
Is this work going to get rid of all native scrollbars?
Please?
Comment 22•23 years ago
|
||
bryner has promised me that it will. I asked him several times. :-)
Comment 24•23 years ago
|
||
bug 124569 may be the duplicate
Comment 25•23 years ago
|
||
XBL form controls will not be turned on for 0.9.9. -> 1.0.
Target Milestone: mozilla0.9.9 → mozilla1.0
Comment 26•23 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
Comment 27•23 years ago
|
||
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•23 years ago
|
||
adding self to cc list
Comment 29•23 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.
Comment 30•23 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.
Comment 31•23 years ago
|
||
Attachment #73868 -
Attachment mime type: text/plain → image/gif
Comment 32•23 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•23 years ago
|
||
Is there any plan to make form text frames (<input type=text> and <textarea>)
skinable?
Updated•23 years ago
|
Whiteboard: [Hixie-P5][wgate] → [Hixie-P5][wgate][adt1]
Comment 34•23 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).
Comment 37•23 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
Comment 38•23 years ago
|
||
At a feature meeting, it was decided that this doesn't need to be nsbeta1+ anymore.
Comment 39•23 years ago
|
||
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]
Comment 40•22 years ago
|
||
Sorry for the spam, but is this still planned on implementing fully in the near
future?
Comment 41•22 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.)
Comment 42•22 years ago
|
||
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•22 years ago
|
||
Comment 44•22 years ago
|
||
Comment 45•22 years ago
|
||
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•22 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•22 years ago
|
||
batch: adding topembed per Gecko2 document
http://rocknroll.mcom.com/users/marek/publish/Gecko/Gecko2Tasks.html
Keywords: topembed
Comment 48•22 years ago
|
||
Topembed- as this is not blocking a major embedding customer.
Comment 49•22 years ago
|
||
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•22 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?
Comment 51•22 years ago
|
||
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•22 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•22 years ago
|
Summary: Rewrite HTML form controls using XBL (XBL form controls) → Rewrite HTML form controls using XBL (XBL form controls) [t2]
Updated•22 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•22 years ago
|
||
This is blocking XForms, which is needed for corporate customers. Nsenterpise.
Target Milestone needs updating. Nominating for 1.3.
Comment 54•22 years ago
|
||
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•22 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.
Updated•22 years ago
|
Target Milestone: mozilla1.0.1 → Future
Comment 56•22 years ago
|
||
How do I enable XBL Form Controls when building Mozilla? Is there a .mozconfig
option?
Comment 57•22 years ago
|
||
Nathan:
It's actually a pref, see Comment #17
It's even accessible in the debug pref panel...
Comment 58•22 years ago
|
||
um, kairo, that pref does not currently work because the files necessary for it
are not packaged with mozilla.
Comment 59•22 years ago
|
||
um, biesi, if that's right, then it's a bug that it shows up in the debug pref
panel...
Comment 60•22 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!?
Comment 61•22 years ago
|
||
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•22 years ago
|
||
Is there a HOWTO that would help with this, Boris? I'm willing to learn, but IANAP.
Comment 63•22 years ago
|
||
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.
Comment 64•21 years ago
|
||
*** Bug 223372 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Assignee: bryner → nobody
Severity: normal → enhancement
Status: ASSIGNED → NEW
Keywords: mozilla1.3,
nsbeta1-,
nsenterprise,
topembed-
QA Contact: vladimire → core.layout.form-controls
Comment 65•18 years ago
|
||
reso/Wontfix per roc
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WONTFIX
Comment 66•18 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.
Description
•