Closed Bug 388583 Opened 17 years ago Closed 17 years ago

Autocomplete dropdown doesn't update when scrolling with scrollbar

Categories

(Core :: XUL, defect)

1.8 Branch
PowerPC
macOS
defect
Not set
normal

Tracking

()

VERIFIED FIXED

People

(Reporter: circleof5th, Assigned: roc)

References

Details

(6 keywords)

Attachments

(1 file, 1 obsolete file)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 in the place where u enter url(s), when u click for the dropdown menu, the scrollbar can move, but the url(s) don't change. It's as if they were stuck. Reproducible: Always Steps to Reproduce: 1.open firefox 2.click on the dropdown menu 3.scroll Actual Results: nothing happens. Expected Results: display all my previously browsed addresses.
Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 Confirmed regression from Firefox 2.0.0.4. I'll work on finding a regression range.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: the dropdown menu for the url(s) doesn't scroll. → Autocomplete dropdown doesn't update when scrolling with scrollbar
Version: unspecified → 2.0 Branch
Blocks: 344228
Component: General → XP Toolkit/Widgets: XUL
Product: Firefox → Core
QA Contact: general → xptoolkit.xul
Version: 2.0 Branch → 1.8 Branch
fwiw, I don't seem to be able to reproduce this on SeaMonkey (latest branch build).
(Mac OS 10.3.9)
I see it on FIrefox. This is a pretty bad branch regression.
(should be Mac only though, at least)
Attached patch a guess fix. (obsolete) — — Splinter Review
I don't have a mac, so can't test whether this works. Anyone willing to try? Does the problem occur only when dragging scrollbar?
Flags: blocking1.8.1.6?
If the patch fixes this, the regression is from bug 382444.
Attached patch fix — — Splinter Review
This is the right fix. The problem is that nsNativeScrollbarFrame::Hookup is called from nsNativeScrollbarFrame::GetPrefSize. The first time it runs it interposes itself as the scrollbar mediator: it keeps a reference to the old scrollbar mediator, makes itself the new scrollbar mediator, and forwards messages from the scrollbar to the old mediator. But the fix for bug 382444 is setting the scrollbar mediator after GetPrefSize has run for the first time. So nsNativeScrollbarFrame thinks there is no mediator and doesn't install itself as a mediator, so never passes events to the tree's mediator even after the tree has installed it. The right thing to do is to just always make the scrollframe a mediator always. Every time a mediator event happens we recheck whether there's a real mediator (this already happens in nsNativeScrollbarFrame::FindParts). We also need to make nsNativeScrollbar always perform regular scrolling *and* mediator notification. Good thing native scrollbars are gone on trunk! I guess basically all tree scrolling is broken on Mac in 2.0.0.5 :-(
Assignee: nobody → roc
Status: NEW → ASSIGNED
Attachment #272879 - Flags: superreview?(mats.palmgren)
Attachment #272879 - Flags: review?(Olli.Pettay)
The blame for this is mainly mine. My patch changed things so that SetScrollbarMediator has to be called before GetPrefSize is called on the scrollbar (an unintentional and stupid requirement). No-one noticed because all our code was doing that. Then Olli checked in his tree patch and violated the requirement.
Thunderbird 2.0.0.5 hasn't been released yet. I guess this is something of a show-stopper for that, right?
Flags: in-litmus?
roc: Tomcat and I don't see scrolling broken on the Thunderbird 2.0.0.5pre build. We are able to scroll the message pane as well as the account pane (not great experience but the scroll bar chunks through). Since this is core code I guess we are puzzled why it wouldn't break in both products. Can you enlighten us? (In reply to comment #9) > Created an attachment (id=272879) [details] > fix > > This is the right fix. > > The problem is that nsNativeScrollbarFrame::Hookup is called from > nsNativeScrollbarFrame::GetPrefSize. The first time it runs it interposes > itself as the scrollbar mediator: it keeps a reference to the old scrollbar > mediator, makes itself the new scrollbar mediator, and forwards messages from > the scrollbar to the old mediator. > > But the fix for bug 382444 is setting the scrollbar mediator after GetPrefSize > has run for the first time. So nsNativeScrollbarFrame thinks there is no > mediator and doesn't install itself as a mediator, so never passes events to > the tree's mediator even after the tree has installed it. > > The right thing to do is to just always make the scrollframe a mediator always. > Every time a mediator event happens we recheck whether there's a real mediator > (this already happens in nsNativeScrollbarFrame::FindParts). We also need to > make nsNativeScrollbar always perform regular scrolling *and* mediator > notification. > > Good thing native scrollbars are gone on trunk! > > I guess basically all tree scrolling is broken on Mac in 2.0.0.5 :-( >
Did you test on Mac? This is Mac only. If it works on Mac then I'm confused.
Yes, I tested on an Intel Mac running 10.4.10. (In reply to comment #13) > Did you test on Mac? This is Mac only. If it works on Mac then I'm confused. >
This also affects the "Message Filters" dialog in Thunderbird on Mac (2.0.0.5 candidates), if you overflow the message criteria, and try to scroll in a folder picket which has scrollbars, like the "Move message to" criterion.
Preed told me to mention this here.... This affects the Password Manager also on Mac... I renamed a username for a login account on a site I manage tonight, and then logged out and logged back in to try to save the new username in password manager. Then I went to the preferences and into Password Manager to attempt to delete the old username since it'll never be used again, and the scrollbar seemed to start scrolling then stopped, and wouldn't start scrolling again. So I never did get to that username to delete it.
ah, to clarify, the scrollbar itself works, but the content stops moving.
You can probably select an entry and then use keyboard navigation to get down to the one you want. Mousewheel also works if you have one. I'm just saying that for completeness .... this regression sucks.
Comment on attachment 272879 [details] [diff] [review] fix >Index: widget/src/mac/nsNativeScrollbar.cpp >=================================================================== >RCS file: /cvsroot/mozilla/widget/src/mac/nsNativeScrollbar.cpp,v >retrieving revision 1.12.4.2 >diff -u -p -1 -2 -r1.12.4.2 nsNativeScrollbar.cpp >--- widget/src/mac/nsNativeScrollbar.cpp 8 May 2006 20:53:48 -0000 1.12.4.2 >+++ widget/src/mac/nsNativeScrollbar.cpp 18 Jul 2007 23:05:09 -0000 >@@ -229,31 +229,29 @@ nsNativeScrollbar::DoScrollAction(Contro > return; > } > > if (buttonPress) { > // > // For the up/down buttons, scroll up or down by the line height and > // update the attributes on the content node (the scroll frame listens > // for these attributes and will scroll accordingly). However, > // if we have a mediator, we're in an outliner and we have to scroll by > // lines. Outliner ignores the indexes in ScrollbarButtonPressed() except > // to check if one is greater than the other to indicate direction. > // >+ UpdateContentPosition(newPos); > if (mMediator) { > BoundsCheck(0, newPos, mMaxValue); > mMediator->ScrollbarButtonPressed(mScrollbar, oldPos, newPos); > } >- else { >- UpdateContentPosition(newPos); >- } > } > else { > // > // For page up/down and dragging the thumb, scroll by the page height > // (or directly report the value of the scrollbar) and update the attributes > // on the content node (as above). If we have a mediator, we're in an > // outliner so tell it directly that the position has changed. Note that > // outliner takes the new position as a signed reference, so we have to > // convert our unsigned to signed first. > // > UpdateContentPosition(newPos); Couldn't you have just one UpdateContentPosition(newPos), right before |if (buttonPress)|?
Attachment #272879 - Flags: review?(Olli.Pettay) → review+
Attachment #272867 - Attachment is obsolete: true
I added this fix to SeaMonkey 1.1.3 (I did minibranch the files for that but unfortunately hit the wrong branch when wanting to check in on that minibranch, I did back out immediately - sorry!)
Attachment #272879 - Flags: superreview?(mats.palmgren) → superreview+
Comment on attachment 272879 [details] [diff] [review] fix Need branch approvals for this major regression.
Attachment #272879 - Flags: approval1.8.1.6?
Attachment #272879 - Flags: approval1.8.0.13?
Blocks: 382444
Flags: blocking1.8.1.6?
Flags: blocking1.8.1.6+
Flags: blocking1.8.0.13+
Flags: blocking1.8.1.6+
Comment on attachment 272879 [details] [diff] [review] fix a=mconnor on behalf of drivers, please land on GECKO181_20070712_RELBRANCH for 2.0.0.6 and MOZILLA_1_8_BRANCH for 2.0.0.7
Attachment #272879 - Flags: approval1.8.1.7?
Attachment #272879 - Flags: approval1.8.1.7+
Attachment #272879 - Flags: approval1.8.1.6+
(In reply to comment #0) > User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; > rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 > Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; > rv:1.8.1.5) Gecko/20070713 Firefox/2.0.0.5 > > in the place where u enter url(s), when u click for the dropdown menu, the > scrollbar can move, but the url(s) don't change. It's as if they were stuck. > > Reproducible: Always > > Steps to Reproduce: > 1.open firefox > 2.click on the dropdown menu > 3.scroll > Actual Results: > nothing happens. > > Expected Results: > display all my previously browsed addresses. > I got mine to work using the mousewheel! You may have to jiggle the scrollbar a bit to get mousewheel to work.
Checked into GECKO181_20070712_RELBRANCH and MOZILLA_1_8_BRANCH.
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
verified fixed 1.8.1.6 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.6) Gecko/2007072301 Firefox/2.0.0.6 autocomplete dropdown/scrollbar works now as expected. Adding verified keyword
MIGHT BE NICE IF FIREFOX FIXED IT. ALL THESE CC'S ARE GREEK AND SERVE NO PURPOSE.
(In reply to comment #38) > verified fixed 1.8.1.6 using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; > rv:1.8.1.6) Gecko/2007072301 Firefox/2.0.0.6 autocomplete dropdown/scrollbar > works now as expected. Adding verified keyword > what about PPC-based Mac?
Verified fixed on PPC using Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.1.6) Gecko/2007072301 Firefox/2.0.0.6. Scrollbars work lovely in the URL bar and elsewhere. > > what about PPC-based Mac? >
Alright in all honesty this is greek to most of us. How do you implement the fix, alot of us are having issues because we don't know how to, so how about a walk through on that.
Chris: If you don't compile builds yourself, then either go back to Firefox 2.0.0.4 (which is bad as it has security issues), wait for Firefox 2.0.0.6, which should be available soon (there might test builds somewhere already), or use SeaMonkey 1.1.3 which has the fix (not that I want to force anyone to convert from Firefox to SeaMonkey here though). Your best option is probably to wait for Firefox 2.0.0.6 which should be available soon.
Robert, Thanks. I've compiled builds, but never for firefox and never for a mac. If 2.0.0.6 will be out soon I can just wait. Thanks for the help. Chris
Status: RESOLVED → VERIFIED
Keywords: fixed1.8.1.7pp
Keywords: fixed1.8.1.7
Comment on attachment 272879 [details] [diff] [review] fix approved for 1.8.0.13, a=dveditz for release-drivers
Attachment #272879 - Flags: approval1.8.0.13? → approval1.8.0.13+
Fix checked into 1.8.0.13
Keywords: fixed1.8.0.13
Verified on MacIntel using Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7pre) Gecko/2007082105 BonEcho/2.0.0.7pre, and Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.7pre) Gecko/2007082103 Thunderbird/2.0.0.7pre Adding verified keyword. I was not able to observe the problem on Thunderbird 15012 or 15013.
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
minusing my original nomination for in-litmus as I don't feel we need a test case for this.
Flags: in-litmus? → in-litmus-
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: