Order of Sidebar tabs not correct in first browser window

RESOLVED FIXED in mozilla1.0

Status

SeaMonkey
Sidebar
P3
normal
RESOLVED FIXED
18 years ago
14 years ago

People

(Reporter: verah (gone), Assigned: shliang)

Tracking

Trunk
mozilla1.0
x86
Windows 95

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [adt2 rtm])

Attachments

(4 attachments)

(Reporter)

Description

18 years ago
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

18 years ago
Created attachment 16247 [details]
Search tab on top... but I set What's Related to be first

Comment 2

18 years ago
Created attachment 16250 [details]
Another example screen shot of out of order

Comment 3

18 years ago
Created attachment 16251 [details]
my profile's panels.rdf file that had this problem

Comment 4

18 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

18 years ago
Sometimes when starting Mozilla, the Sidebar panel are also out of order.

Comment 6

18 years ago
*** Bug 55994 has been marked as a duplicate of this bug. ***
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

18 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

18 years ago
cc hewitt for possible insight

Updated

18 years ago
Group: mozillaorgconfidential?

Comment 10

18 years ago
.
(Reporter)

Comment 11

18 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 12

18 years ago
spam : changing qa to sujay (New Sidebar QA)
QA Contact: shrir → sujay

Comment 13

17 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

17 years ago
*** Bug 58793 has been marked as a duplicate of this bug. ***

Comment 15

17 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.

Keywords: correctness, nsbeta1, nsCatFood
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. 
Keywords: nsbeta1, nsCatFood → nsbeta1+, nsCatFood+
Priority: P3 → P4
Target Milestone: --- → mozilla1.0.1

Comment 17

17 years ago
*** Bug 87986 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Keywords: nsbranch

Comment 18

17 years ago
reassigning to tpringle to track for later release
Assignee: matt → tpringle

Comment 19

17 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 20

17 years ago
reassigning to Samir.
Assignee: tpringle → sgehani

Comment 21

17 years ago
*** Bug 111474 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Target Milestone: mozilla1.0.1 → mozilla0.9.8

Comment 22

17 years ago
*** Bug 114488 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Whiteboard: [RTM-] → [RTM-] test across sessions when this is fixed..

Comment 23

17 years ago
*** Bug 114597 has been marked as a duplicate of this bug. ***

Comment 24

17 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

17 years ago
Target Milestone: mozilla0.9.8 → mozilla0.9.9
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 26

17 years ago
bumping to p3, nominating for nsbeta1
Keywords: nsbeta1
Priority: P4 → P3
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 28

17 years ago
-> mozilla1.0
Target Milestone: mozilla0.9.9 → mozilla1.0

Comment 29

17 years ago
Sidebar triage team: nsbeta1+
Keywords: nsbeta1 → nsbeta1+

Comment 30

17 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

17 years ago
I've seen this on Win98, so it seems to affect (at least) win9x/ME.

Comment 32

17 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. 

Comment 33

17 years ago
adt triage: nsbeta1-
Keywords: nsbeta1+ → nsbeta1-

Updated

17 years ago
Target Milestone: mozilla1.0 → mozilla1.2

Comment 34

17 years ago
Renominating based on discussion with trudelle.
Keywords: nsbeta1- → nsbeta1

Comment 35

17 years ago
ADT: this defect becomes particularly confusing for users given the new tab
navigation feature in the sidebar.

Comment 36

17 years ago
nsbeta1+ per Nav triage team, ->1.0, nav2
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [RTM-] test across sessions when this is fixed.. → [RTM-] test across sessions when this is fixed.. [nav2]
Target Milestone: mozilla1.2alpha → mozilla1.0

Comment 37

16 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

16 years ago
adding self to cc list

Comment 39

16 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

16 years ago
Whiteboard: [RTM-] test across sessions when this is fixed.. [adt2] → test across sessions when this is fixed.. [adt2]

Updated

16 years ago
Whiteboard: test across sessions when this is fixed.. [adt2] → [adt2]
*** Bug 138189 has been marked as a duplicate of this bug. ***

Comment 41

16 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

16 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

16 years ago
Created attachment 83903 [details] [diff] [review]
Patch v1.0.

Updated

16 years ago
Keywords: patch

Updated

16 years ago
Whiteboard: [adt2] → [adt2 rtm]

Comment 44

16 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 on attachment 83903 [details] [diff] [review]
Patch v1.0.

r=rjc
Attachment #83903 - Flags: review+

Comment 46

16 years ago
Comment on attachment 83903 [details] [diff] [review]
Patch v1.0.

sr=hewitt
Attachment #83903 - Flags: superreview+

Comment 47

16 years ago
Bring on adt's radar (adt1.0.1 keyword added).
Keywords: adt1.0.1

Comment 48

16 years ago
adt1.0.1- per adt
Keywords: adt1.0.1 → adt1.0.1-

Comment 49

16 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.
Blocks: 143047
Keywords: adt1.0.1- → adt1.0.1+, approval

Comment 50

16 years ago
Patch for bug 134345 fixed this as well on the branch.
Keywords: approval → fixed1.0.1

Updated

16 years ago
Keywords: fixed1.0.1 → verified1.0.1

Updated

16 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 51

16 years ago
reassigning
Assignee: sgehani → shliang
Status: ASSIGNED → NEW
(Assignee)

Comment 52

16 years ago
fixed
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED

Comment 53

16 years ago
*** Bug 195710 has been marked as a duplicate of this bug. ***

Comment 54

16 years ago
*** Bug 195906 has been marked as a duplicate of this bug. ***

Comment 55

16 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).
QA Contact: sujay → petersen
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.