Closed Bug 350257 Opened 13 years ago Closed 13 years ago

"increment" in numberbox is doubled if it's in chrome

Categories

(Toolkit :: XUL Widgets, defect)

defect
Not set

Tracking

()

VERIFIED FIXED

People

(Reporter: torisugari, Assigned: enndeakin)

References

Details

Attachments

(1 file, 1 obsolete file)

If the xul file has the chrome privilege, both "up" event
handler and "onup" hadler will be called on pusing up button.
So they increments the number twice in total.

steps to reproduce:
1. Create a xul file with <textbox type="number" increment="10"/>
2. Unzip browser.jar, put the file anywhere and rezip it.
3. Access the xul file with chrome://.../ URI
4. Push "Up" button.

Expected result:
0 -> 10

Actual result:
0 -> 20

This is reproducible on Linux and Windows, and when I wrote
a extension as well. However, it's not reproducible if the 
URL is "file://..." or "http://..."
Attached patch fix up/down events (obsolete) — Splinter Review
How strange. Remove the extra event handlers.
Assignee: nobody → enndeakin
Status: UNCONFIRMED → ASSIGNED
Attachment #235512 - Flags: first-review?(neil)
Depends on: 350334
Duplicate of this bug: 368387
Neil, review this bug! ;)
The question is, will you refix it correctly when bug 350334 gets fixed?
Comment on attachment 235512 [details] [diff] [review]
fix up/down events

Now that bug 350334 is fixed please remove the "other" extra event handlers ;-)
Attachment #235512 - Flags: first-review?(neil) → first-review-
Attachment #235512 - Attachment is obsolete: true
Attachment #261604 - Flags: first-review?(neil)
Comment on attachment 261604 [details] [diff] [review]
remove extra event handlers

BTW does <textbox type="number"> work with toolkit's <prefwindow> ?
(XPFE's wsm doesn't seem to like it.)
Attachment #261604 - Flags: first-review?(neil) → first-review+
(In reply to comment #7)
> (From update of attachment 261604 [details] [diff] [review])
> BTW does <textbox type="number"> work with toolkit's <prefwindow> ?
> (XPFE's wsm doesn't seem to like it.)
>

Yes, numberbox in prefwindow should work fine on Firefox. I haven't
tested this XUL element recently, but when I filed this bug, I was
writing something <textbox type="number" pref="foo"/> in prefwindow.
Bleah. Is there a bug on making wsm play nice, or alternately one on moving mail account management to something that doesn't use it, that I can be blocked on bug 376975 by?
(In reply to comment #9)
>Is there a bug on making wsm play nice, or alternately one on moving mail
>account management to something that doesn't use it
Mail account management never used it (wsm doesn't support multiple accounts).
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Is there a test covering this in the widget suite?
Flags: in-testsuite?
Thanks. ->v
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.