Closed
Bug 662191
Opened 13 years ago
Closed 13 years ago
Profile name are blank in the listbox of Profile manager when scroll the listbox by mouse wheel.
Categories
(Toolkit :: UI Widgets, defect)
Toolkit
UI Widgets
Tracking
()
RESOLVED
FIXED
mozilla7
People
(Reporter: alice0775, Assigned: masayuki)
References
Details
Attachments
(1 file)
1010 bytes,
patch
|
smaug
:
review+
enndeakin
:
review+
|
Details | Diff | Splinter Review |
Build Identifier: http://hg.mozilla.org/mozilla-central/rev/4f9bbea16f75 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0a1) Gecko/20110605 Firefox/7.0a1 ID:20110605030701 If there are too many profile in Profile Manager and The manager have scroll bar. Profile name are blank in the listbox of Profile manager when scroll the listbox by mouse wheel. This happens on Windows 7 Classic Style. This does _not_ happen on Windows 7 Aero Style and Ubuntu 10.04 Gnome2. Screen Capture: http://www.youtube.com/watch?v=CQVLU9CvkW0 Reproducible: Always Steps to Reproduce: 1. Execute Firefox.exe -P 2. Create 10 profiles(Ex. 11, 22, 33, 44, 55, 66, 77, 88, 99, 00) 3. Select 2nd profile(Ex. 22) and Start Nightly 4. Quit Firefox 5. Execute Firefox.exe -P 6. Turn mouse wheel 1 tick on the listbox Actual Results: 9th and 10th profile name are blank. Turn mouse wheel 1 more tick on the listbox, these profile names appear. Expected Results: Profile name should appear properly when scroll the listbox by mouse wheel. Regression window: Works: http://hg.mozilla.org/mozilla-central/rev/3e7a21049b6c Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110516 Firefox/6.0a1 ID:20110516160657 Fails: http://hg.mozilla.org/mozilla-central/rev/0a1e7ec7e268 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110516 Firefox/6.0a1 ID:20110516172821 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3e7a21049b6c&tochange=0a1e7ec7e268 Triggered by: 0a1e7ec7e268 Masayuki Nakano — Bug 605648 Support high resolution scrolling on Windows r=jimm+smaug
Assignee | ||
Comment 1•13 years ago
|
||
This is not actually a regression. It's odd. The listbox of Profile Manager handles pixel scrolling events only first some times. After that, it only handles line scrolling events. The repainting problem might be caused being assumed not to be scrolled by pixel unit. I can also see same issue on Mac.
OS: Windows 7 → Windows XP
Assignee | ||
Updated•13 years ago
|
Assignee: nobody → masayuki
Component: General → XUL Widgets
OS: Windows XP → All
Product: Firefox → Toolkit
QA Contact: general → xul.widgets
Hardware: x86 → All
Assignee | ||
Comment 2•13 years ago
|
||
If the delta value didn't reach to 1 line, pixel scrolling events were dispatched without line scrolling event. The pixel scroll event will be handled by nsEventStateManager because the event state isn't consume-no-default. I think XUL listbox widget should consume the pixel scrolling event because it doesn't support pixel level scrolling. I'll request the review to toolkit peer, if smaug agree with my idea.
Attachment #537506 -
Flags: review?(Olli.Pettay)
Assignee | ||
Updated•13 years ago
|
Status: NEW → ASSIGNED
Keywords: regression
Assignee | ||
Comment 3•13 years ago
|
||
(In reply to comment #0) > This happens on Windows 7 Classic Style. > This does _not_ happen on Windows 7 Aero Style and Ubuntu 10.04 Gnome2. And I can reproduce this bug on Win7 even if I use Aero. You must not be able to reproduce this on Linux because Linux doesn't support pixel scrolling.
Updated•13 years ago
|
Attachment #537506 -
Flags: review?(Olli.Pettay) → review+
Assignee | ||
Comment 4•13 years ago
|
||
Comment on attachment 537506 [details] [diff] [review] Patch v1.0 Enn, please see above comment for the detail.
Attachment #537506 -
Flags: review?(enndeakin)
Updated•13 years ago
|
Attachment #537506 -
Flags: review?(enndeakin) → review+
Assignee | ||
Comment 5•13 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/dd46dcb7441a
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
Comment 6•13 years ago
|
||
What about the other 4 uses in toolkit/content/widgets?
Assignee | ||
Comment 7•13 years ago
|
||
(In reply to comment #6) > What about the other 4 uses in toolkit/content/widgets? 4? I don't find 4 uses, would you list them? I found richlistbox which supports pixel level scrolling even though it inherits listbox-base. On it, the patch makes new regression. I'll back it out tomorrow. I cannot do it from now because it's midnight right now... Neil, if you do it, feel free to do it.
Assignee | ||
Comment 8•13 years ago
|
||
(In reply to comment #7) > (In reply to comment #6) > I found richlistbox which supports pixel level scrolling even though it > inherits listbox-base. On it, the patch makes new regression. I'll back it > out tomorrow. I cannot do it from now because it's midnight right now... > Neil, if you do it, feel free to do it. Um, this might be wrong. It's to difficult to test it. I'll investigate whether there is a regression actually tomorrow.
Comment 9•13 years ago
|
||
(In reply to comment #7) > (In reply to comment #6) > > What about the other 4 uses in toolkit/content/widgets? > 4? I don't find 4 uses, would you list them? Well, the other files that use DOMMouseScroll are datepicker.xml scrollbox.xml tabbox.xml and tree.xml so I was concerned that they might need to be changed.
Assignee | ||
Comment 10•13 years ago
|
||
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > I found richlistbox which supports pixel level scrolling even though it > > inherits listbox-base. On it, the patch makes new regression. I'll back it > > out tomorrow. I cannot do it from now because it's midnight right now... > > Neil, if you do it, feel free to do it. > > Um, this might be wrong. It's to difficult to test it. I'll investigate > whether there is a regression actually tomorrow. I retested with debugger. On richlistbox, pixel scrolling event wasn't consumed by it and nsEventStateManager::DoScrollText() correctly. So, the patch doesn't regress. (In reply to comment #9) > (In reply to comment #7) > > (In reply to comment #6) > > > What about the other 4 uses in toolkit/content/widgets? > > 4? I don't find 4 uses, would you list them? > Well, the other files that use DOMMouseScroll are datepicker.xml > scrollbox.xml tabbox.xml and tree.xml so I was concerned that they might > need to be changed. I guess datepiccker and tabbox don't need because perhaps, they are not actually scrolled by ESM. The others might need but I'm not sure.
Reporter | ||
Comment 11•13 years ago
|
||
This bug also affected Aurora/Firefox6.0a2.
Assignee | ||
Comment 12•13 years ago
|
||
(In reply to comment #11) > This bug also affected Aurora/Firefox6.0a2. I don't think it's worth. (risk vs. return)
Reporter | ||
Comment 13•13 years ago
|
||
In reply to comment #12) > (In reply to comment #11) > > This bug also affected Aurora/Firefox6.0a2. > > I don't think it's worth. (risk vs. return) OK It affects. However we would not fix it for Aurora/Firefox6.0a2 because there is a risk.
Assignee | ||
Comment 14•13 years ago
|
||
(In reply to comment #13) > In reply to comment #12) > > (In reply to comment #11) > > > This bug also affected Aurora/Firefox6.0a2. > > > > I don't think it's worth. (risk vs. return) > OK > It affects. > However we would not fix it for Aurora/Firefox6.0a2 because there is a risk. On Mac, you can see this bug with Fx5 and earlier too.
Reporter | ||
Comment 15•13 years ago
|
||
(In reply to comment #14) > (In reply to comment #13) > > In reply to comment #12) > > > (In reply to comment #11) > > > > This bug also affected Aurora/Firefox6.0a2. > > > > > > I don't think it's worth. (risk vs. return) > > OK > > It affects. > > However we would not fix it for Aurora/Firefox6.0a2 because there is a risk. > > On Mac, you can see this bug with Fx5 and earlier too. Sorry, I'm talking about Fx6 on windows.
You need to log in
before you can comment on or make changes to this bug.
Description
•