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)

defect
Not set
trivial

Tracking

()

RESOLVED FIXED
mozilla7

People

(Reporter: alice0775, Assigned: masayuki)

References

Details

Attachments

(1 file)

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
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: nobody → masayuki
Component: General → XUL Widgets
OS: Windows XP → All
Product: Firefox → Toolkit
QA Contact: general → xul.widgets
Hardware: x86 → All
Attached patch Patch v1.0Splinter Review
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)
Status: NEW → ASSIGNED
Keywords: regression
(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.
Attachment #537506 - Flags: review?(Olli.Pettay) → review+
Comment on attachment 537506 [details] [diff] [review]
Patch v1.0

Enn, please see above comment for the detail.
Attachment #537506 - Flags: review?(enndeakin)
Attachment #537506 - Flags: review?(enndeakin) → review+
http://hg.mozilla.org/mozilla-central/rev/dd46dcb7441a
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla7
What about the other 4 uses in toolkit/content/widgets?
(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.
(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.
(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.
(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.
This bug also affected Aurora/Firefox6.0a2.
(In reply to comment #11)
> This bug also affected Aurora/Firefox6.0a2.

I don't think it's worth. (risk vs. return)
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.
(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.
(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.

Attachment

General

Created:
Updated:
Size: