Closed
Bug 540340
Opened 15 years ago
Closed 14 years ago
In the initial loading of the show cookie dialogue, the tree of the list of cookies scrolls to 2nd line.
Categories
(Firefox :: Settings UI, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | - |
People
(Reporter: alice0775, Assigned: enndeakin)
References
Details
(Keywords: regression)
Attachments
(1 file, 1 obsolete file)
7.83 KB,
patch
|
neil
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100117 Firefox/3.5.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100117 Namoroka/3.6pre ID:20100117053836 In the initial loading of the show cookie dialogue, the tree of the list of cookies scrolls to 2nd row. Though the first row is selected, it is displayed by the second row. Reproducible: Always Steps to Reproduce: 1.Start Namoroka/Minfield 2.(If necessary)Navigate several web site. and store enough number of cookies. 3.Tools > Options... > Plivacy 4.Select "Use custom setting for history" in the history group. 5.Click "Show Cookies..." Actual Results: The tree of the list of cookies scrolls to 2nd row. Expected Results: The tree of the list of cookies should scroll to 1nd row. This issue happens on Namoroka and Minefield. Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2pre) Gecko/20100117 Namoroka/3.6pre ID:20100117053836 Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a1pre) Gecko/20100116 Minefield/3.7a1pre ID:20100116051420
Reporter | ||
Updated•15 years ago
|
Version: unspecified → 3.6 Branch
Reporter | ||
Comment 1•15 years ago
|
||
Regression window: Works: http://hg.mozilla.org/mozilla-central/rev/9dbded90af2a Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090113 Firefox/3.2a1pre ID:20090113035246 Broken: http://hg.mozilla.org/mozilla-central/rev/89811ac1b35a Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2a1pre) Gecko/20090114 Firefox/3.2a1pre ID:20090114034711 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=9dbded90af2a&tochange=89811ac1b35a Candidate regress bug: Bug 454632 - Resizing tree widget always re-scrolls to current index
Keywords: regression
Reporter | ||
Comment 2•15 years ago
|
||
(In reply to comment #0) s/1nd/1st/
Comment 3•15 years ago
|
||
the issue isn't limited to initially opening this window, but also explicit selecting the fist entry and reopening the dialogue afterwards.
Blocks: 454632
Reporter | ||
Comment 4•15 years ago
|
||
And It happens in Tools > Options... > Content "Allowed Sites - Popups" and "Exceptions - Images" window.
Updated•15 years ago
|
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Assignee | ||
Comment 5•14 years ago
|
||
The fix is in EnsureRowIsVisibleInternal to check if mPageLength is 0 before scrolling. I also cleaned up some return values in the scroll methods as most were unused I need to work out what is special about the cookies and other dialogs in order to create a test.
Comment 6•14 years ago
|
||
Comment on attachment 424114 [details] [diff] [review] check page length before scrolling, and clean up return values >- nsresult rv = EnsureRowIsVisibleInternal(parts, aRow); >- NS_ENSURE_SUCCESS(rv, rv); >- UpdateScrollbars(parts); >- return rv; >-} >- >-nsresult nsTreeBodyFrame::EnsureRowIsVisibleInternal(const ScrollParts& aParts, PRInt32 aRow) >-{ >- if (!mView) >- return NS_OK; >+ EnsureRowIsVisibleInternal(parts, aRow); >+ UpdateScrollbars(parts); >+ return NS_OK; >+} Sigh, hg diff made a mountain out of a molehill. Maybe separate cleanup? >+ if (!mView || !mPageLength) >+ return; > > if (mTopRowIndex <= aRow && mTopRowIndex+mPageLength > aRow) >- return NS_OK; >- >- if (aRow < mTopRowIndex) >- ScrollToRowInternal(aParts, aRow); >- else { >- // Bring it just on-screen. >- PRInt32 distance = aRow - (mTopRowIndex+mPageLength)+1; >- ScrollToRowInternal(aParts, mTopRowIndex+distance); >- } IMHO mPageLength can legally be zero, but that's no excuse to miscalculate which row to scroll to. On the other hand I rather like the idea that keepcurrentinview will have no effect when the tree is collapsed. >- // Our internal scroll method, used by all the public scroll methods. >- nsresult ScrollInternal(const ScrollParts& aParts, PRInt32 aRow); >- nsresult ScrollToRowInternal(const ScrollParts& aParts, PRInt32 aRow); >+ // Our internal scroll methods, used by all the public scroll methods. >+ void ScrollInternal(const ScrollParts& aParts, PRInt32 aRow); > nsresult ScrollToColumnInternal(const ScrollParts& aParts, nsITreeColumn* aCol); I'd rather we keep the name ScrollToRowInternal.
Assignee | ||
Comment 7•14 years ago
|
||
Hopefully Neil will decide what behaviour he likes here.
Attachment #424114 -
Attachment is obsolete: true
Attachment #424237 -
Flags: review?(neil)
Attachment #424114 -
Flags: review?(neil)
Comment 8•14 years ago
|
||
Comment on attachment 424237 [details] [diff] [review] this version excludes the cleanup but adds a test OK, let's give this a whirl.
Attachment #424237 -
Flags: review?(neil) → review+
Assignee | ||
Comment 9•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/505db0be4476
Flags: in-testsuite+
Assignee | ||
Updated•14 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•