Closed
Bug 55358
Opened 24 years ago
Closed 22 years ago
Order of Sidebar tabs not correct in first browser window
Categories
(SeaMonkey :: Sidebar, defect, P3)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.0
People
(Reporter: verah, Assigned: shliang)
References
Details
(Whiteboard: [adt2 rtm])
Attachments
(4 files)
18.28 KB,
image/gif
|
Details | |
113.74 KB,
image/jpeg
|
Details | |
5.32 KB,
text/plain
|
Details | |
1.49 KB,
patch
|
mozilla
:
review+
hewitt
:
superreview+
|
Details | Diff | Splinter Review |
I've got my My Sidebar tabs arranged with "What's Related" first, "Search"
second, etc.... This order shows up in the list in the Customize Sidebar dialog
box, and in the Tabs drop-down menu, but it is *not* honored in My Sidebar. See
the gif which I will attach.
Reporter | ||
Comment 1•24 years ago
|
||
I noticed that if I open a new Nav window, the order in the new window was
correct. However, the order remained wrong in the orginal window (screen shot
above) even as I opened and closed My Sidebar.
Adding keyword rtm, then putting in status whiteboard (since I'm with the Nav
triage team) rtm-. This will help us find this later.
Keywords: rtm
Whiteboard: [rtm-]
Comment 5•24 years ago
|
||
Sometimes when starting Mozilla, the Sidebar panel are also out of order.
Comment 7•24 years ago
|
||
so how am i supposed to reorder my sidebar panels if the dialog does the wrong
thing? I'm afraid to touch one of the features that we're touting as new and
spiffy. That's not a good thing.
requesting re-triage.
Whiteboard: [rtm-]
Comment 8•24 years ago
|
||
I would look at this, but I don't see it in a trunk build. Building a new
branch build now to test.
Can anyone confirm that this is modern only? Both this and its dup were
reported against modern, and the screenshot that johng attached was of modern
also.
Group: mozillaorgconfidential?
Comment 9•24 years ago
|
||
cc hewitt for possible insight
Updated•24 years ago
|
Group: mozillaorgconfidential?
Comment 10•24 years ago
|
||
.
Reporter | ||
Comment 11•24 years ago
|
||
Nav triage team: No fix, it's too late, and it's not a "pull it off the wire"
bug. RTM-
Whiteboard: [RTM-]
Comment 13•24 years ago
|
||
Although this is an older bug, I just wanted to add a comment that on the build
I am currently using (Mozilla Build ID 2001041804) - April 18, 2001/Win32, the
sidebar tabs still do not retain the order I set it to.
And, it does not matter what chrome/theme (Modern or Classic) I am using; the
problem remains in both cases.
Comment 14•23 years ago
|
||
*** Bug 58793 has been marked as a duplicate of this bug. ***
Comment 15•23 years ago
|
||
This bug still exists in Netscape 6.1 PR1 public release.
adding the keywords that were part of the duplicate bug 58793. Here is the
intro description to this bug from that duplicate - clearly described by pinkerton:
- put 4 or 5 panels in the sidebar
- select the next to last sidebar
- quit
- relaunch
EXpected:
- sidebar panels are in the same order as when you quit
Actual:
- 2nd to last sidebar at quit time is now the last sidebar
- actual list is out of sync with customize dialog so effects of rearranging are
unknown.
Comment 16•23 years ago
|
||
Kevin: I'm not convinced that this is a common/frequent problem. I'd like to
move it to post NS 6.1, this shd be an early bug to fix for the post NS6.1
product. We tried this out on Win98 and Mac and it seemed to work okay.
Priority: P3 → P4
Target Milestone: --- → mozilla1.0.1
Comment 17•23 years ago
|
||
*** Bug 87986 has been marked as a duplicate of this bug. ***
Comment 18•23 years ago
|
||
reassigning to tpringle to track for later release
Assignee: matt → tpringle
Comment 19•23 years ago
|
||
I'm going to take off the nsbranch on this one. let me know if that is a
boneheaded thing to do.. we ought to get this in the hands of trudelle or
an engineer who could fix...
Keywords: nsbranch
Comment 21•23 years ago
|
||
*** Bug 111474 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla1.0.1 → mozilla0.9.8
Comment 22•23 years ago
|
||
*** Bug 114488 has been marked as a duplicate of this bug. ***
Comment 23•23 years ago
|
||
*** Bug 114597 has been marked as a duplicate of this bug. ***
Comment 24•23 years ago
|
||
Using build 2001121803 this problems still exists
I notice that the tabs are out of order after a reboot
1.With 4 or 5 tabs in the sidebar change the order that they are in
2.Close Netscape and relaunch
3.Notice that the tabs are in the correct order
4.Reboot the computer and launch Netscape
5.Notice that the tabs are not in the correct order
6.Close Netscape and relaunch or just open a new Navigator Window
Actual Results:
After opening a new window the tabs are in the correct order again.
Expected Results:
Tabs should be in the correct order after rebooting the computer.
Updated•23 years ago
|
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Comment 25•23 years ago
|
||
Todd, do we have the right key words and priority on this? This bug is really
annoying and makes using sidebar suck. The reordering problem happens to me
with my first browser window, but subsequent windows the order is correct.
Summary: Ordering of My Sidebar tabs not correct → Ordering of My Sidebar tabs not correct in first browser window
Comment 27•23 years ago
|
||
A couple observations:
Reordering problem happens when I have 3 or more sidebar tabs (it doesn't happen
when I have only two open and of course problem doesn't apply if you have only
one tab).
I've noticed that the problem occurs after a crash, any crash of the browser.
Comment 30•23 years ago
|
||
Re: Comment #16 from Viswanath Ramachandran (OK with Win98, ...)
I have only recently upgraded to WinMe and now have this problem. I
don't remember ever seeing it with Win98.
Comment 31•23 years ago
|
||
I've seen this on Win98, so it seems to affect (at least) win9x/ME.
Comment 32•23 years ago
|
||
The fix in bug 122794 might be completely irrelevant here, but if the sidebar
tab ordering algorithm uses quick sort, it won't.
Updated•23 years ago
|
Target Milestone: mozilla1.0 → mozilla1.2
Comment 34•23 years ago
|
||
Renominating based on discussion with trudelle.
Comment 35•23 years ago
|
||
ADT: this defect becomes particularly confusing for users given the new tab
navigation feature in the sidebar.
Comment 36•23 years ago
|
||
nsbeta1+ per Nav triage team, ->1.0, nav2
Comment 37•23 years ago
|
||
Please update this bug with an [adt1] - [adt3] impact rating (or take it off the
list if it doesn't even rate adt3.) Thanks!
Comment 38•23 years ago
|
||
adding self to cc list
Comment 39•23 years ago
|
||
converting nav2->adt2
Whiteboard: [RTM-] test across sessions when this is fixed.. [nav2] → [RTM-] test across sessions when this is fixed.. [adt2]
Updated•23 years ago
|
Whiteboard: [RTM-] test across sessions when this is fixed.. [adt2] → test across sessions when this is fixed.. [adt2]
Updated•23 years ago
|
Whiteboard: test across sessions when this is fixed.. [adt2] → [adt2]
Comment 40•23 years ago
|
||
*** Bug 138189 has been marked as a duplicate of this bug. ***
Comment 41•23 years ago
|
||
I'm not sure, whether my observation is relevant to this but... currently I'm
using mozilla 1.0 rc1 and it seems, that after Mozilla is restarted, tabs are
displayed in order they are *serialized* in panels.rdf, rather then as listed in
rdf:Seq in this file. After I ordered this file manually order is correct.
Sounds stupid, I know...
(running RH 7.2 installed Mozilla from RPM's)
Comment 42•23 years ago
|
||
Pavel,
Regarding comment 41, your observation has proved very useful. This is in fact
a template builder defect. Thanks for the info!
Comment 43•23 years ago
|
||
Updated•23 years ago
|
Whiteboard: [adt2] → [adt2 rtm]
Comment 44•23 years ago
|
||
Performance tested patch v1.0 using ash on testerbox with the following results:
Ts: improved!
From ~5320ms to ~5290ms yielding a 0.005% startup performance improvement
Txul: degraded ``negligibly''
From ~1735 to ~1770 yielding a 0.02% xul window open degradation
The performance test was conducted on ash wich is a slow box: 300 MHz. The Txul
performance degradation will be even less noticable as the machine configuration
is stronger (more CPU speed, more memory).
This patch also fixes the case where the sidebar is collapsed at startup, then
dragged open and no sidebar contents are displayed (which is a regression
lingering since the mozilla0.9.8 miletsone).
rjc, please r.
hewitt, please sr.
Status: NEW → ASSIGNED
Comment 45•23 years ago
|
||
Comment on attachment 83903 [details] [diff] [review]
Patch v1.0.
r=rjc
Attachment #83903 -
Flags: review+
Comment 46•22 years ago
|
||
Comment on attachment 83903 [details] [diff] [review]
Patch v1.0.
sr=hewitt
Attachment #83903 -
Flags: superreview+
Comment 49•22 years ago
|
||
reversing decision, and taking this one for RTM. adt1.0.1+ (on ADT's behalf)
approval for checkin to the 1.0 branch, pending Driver's approval. pls check
this in asap, then add the "fixed1.0.0" keyword.
Comment 50•22 years ago
|
||
Patch for bug 134345 fixed this as well on the branch.
Keywords: approval → fixed1.0.1
Keywords: fixed1.0.1 → verified1.0.1
Updated•22 years ago
|
Summary: Ordering of My Sidebar tabs not correct in first browser window → Order of Sidebar tabs not correct in first browser window
Assignee | ||
Comment 52•22 years ago
|
||
fixed
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 53•22 years ago
|
||
*** Bug 195710 has been marked as a duplicate of this bug. ***
Comment 54•22 years ago
|
||
*** Bug 195906 has been marked as a duplicate of this bug. ***
Comment 55•22 years ago
|
||
I don't know if it would help, as this bug is marked as fixed, but I want to add
that the order of tabs in the sidebar depends on the _disabled_ tabs.
I have noticed this when I added tab to sidebar (order of tabs in sidebar was
not correct, but I have managed to get related tabs (some linux news portals)
together), and next disabled the added tab, the order of tabs in sidebar changed
(after Mozilla restart of course).
Updated•21 years ago
|
QA Contact: sujay → petersen
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•