Closed Bug 127777 Opened 23 years ago Closed 23 years ago

Site Navigation Bar is hosed

Categories

(SeaMonkey :: UI Design, defect)

x86
All
defect
Not set
major

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: choess, Assigned: sballard)

References

()

Details

<choess> what a mess
<grok> choess: Yep, looks like the link bar is hosed.

When browsing to http://www.w3.org/MarkUp from http://www.w3.org/, it looks like
the toolbar isn't completely re-initialized, and it misses some links.  Giving
this to sballard since he committed to the toolbar most recently, but that may
or may not be the cause (i.e., some apparently unrelated checkin might have
exposed a design error.)
qa->claudius
Blocks: 103053
QA Contact: sairuh → claudius
Um... so what links is it missing?  The page only seems to have on link....
When I go to http://www.w3.org/Markup/, I see a link for "Next" where there
should be none.  Try browsing through the HTML 4.01 Recommendation, section by
section; that's where I first saw it breaking.
I can reproduce this bug with 2002022503/WinXP.
OS: Linux → All
in the case browsing between pages which have LINK rel on 0.9.8.

 case 1) open in same window   - valid. yei, it inits!
 case 2) open in new window    - valid
 case 3) open in new tab       - invalid. damn! it stays the same!
 case 4) switch tab            - invalid

i suppose linkbar init proc is not yet implemented on tab function.
it should be triggered when main toolbar(back|prev|reload|stop) inits.

Hmm...could affect chrome design...?
Is this bug just related to tabs? If so, it's a dup of bug 102905, which has a
hacky patch already. I just tried this in 0.9.8 and only see the "Top" link on
/MarkUp. I haven't got a build handy with the patch from bug 123379 applied, but
I'll test this out as soon as I get a chance. In the meantime, if someone could
clarify whether this is tab-related or not, I'd appreciate it.
Unfortunately, this problem is independent of tabbed browsing.
Let's forget about tabbed browsing in this case.

Here is example steps to reproduce:

0) make sure that your browser is ready for showing Site Navigation Bar.
1) open http://www2.wbs.ne.jp/%7Echado/work/site_navigation/first.html 
   with _NEW_ browser _window_.  you can see only "Top" is activated on 
   the Site Navigation Bar.  
2) click the "Top" icon on the Site Navigation Bar.  you can see "First" and 
   "Previous" are activated.  
3) click the "First" icon to get back First page.  

expected result: 
  only "Top" should be activated as well as step1.  
actual result:  
  "Top", "First" and "Previous" are all activated.  reloading can't fix 
  such a situation.  

also, "Index" should be appeared under "Document" and "dummy" should be 
appeared under "More" are not coming all the time.  you can try one of the 
previous builds and check their behavior.  

builds I've tried:
  milestone 0.9.8     Mac 9 and Win98 work fine
  2002-02-21-08-trunk Mac 9 works fine
  2002-02-22-10-trunk Win98 works fine
! 2002-02-24-08-trunk Mac 9 do not works
! 2002-02-26-03-trunk Mac 9 do not works
! 2002-02-27-09-trunk Win98 do not works

seems to be regression.
Are you sure about 2002-02-22 working fine? The only bug that I've had anything
to do with was bug 123379 and that was checked in Feb 20 22:54 (per
http://bonsai.mozilla.org/cvslog.cgi?file=mozilla/content/html/content/src/nsHTMLLinkElement.cpp
). That would strongly suggest that both the -21- and -22- builds should include
that change.

Therefore, if this bug is related to bug 123379, the -21- and -22- builds should
be broken, and they're not. I can't think of any other linktoolbar-related
checkins that happened in that timeframe... anyone else know of any? choess? bz?

The real test would be to specifically back out 123379 to see if it fixes
anything. I can't see how it would have any effect in this case, but I don't
have any better candidates, or any time right now to do any serious debugging...
This be caused by bug 127557.  JS errors have their way of stopping script
execution and all that...
(seems too late)
I've tried little more minimizing the range of working:  

  2002-02-22-10-trunk Win98 works fine
! 2002-02-22-21-trunk LinuxPPC do not works
- 2002-02-23-03-trunk Mac 9 can't start because of missing "NSRuntime"
! 2002-02-23-08-trunk Mac 9 do not works
! 2002-02-23-11-trunk Win98 do not works
! 2002-02-24-08-trunk Mac 9 do not works

The list is standing on ftp directory name where I have downloaded builds.  

If I've got no misunderstanding, time period matches the checkins bellow, 
including bug 62164 refered from bug 127557.  

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&
filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=02%2F22%2F2002+10%3A00%3A00&
maxdate=02%2F22%2F2002+21%3A00%3A00&cvsroot=%2Fcvsroot
Marking dependent on bug 127557, but I'm wondering if actually it should be
marked as DUP rather than a dependency. In theory, when 127557 is checked in,
this will magically fix. But perhaps I should keep this one open for separate
QAing...
Depends on: 127557
2002030206/Linux works fine.
WFM (original reporter) in a new build.  Resolving WFM.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.