Closed
Bug 127777
Opened 23 years ago
Closed 23 years ago
Site Navigation Bar is hosed
Categories
(SeaMonkey :: UI Design, defect)
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.)
Comment 2•23 years ago
|
||
Um... so what links is it missing? The page only seems to have on link....
Reporter | ||
Comment 3•23 years ago
|
||
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.
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...?
Assignee | ||
Comment 6•23 years ago
|
||
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.
Reporter | ||
Comment 7•23 years ago
|
||
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.
Assignee | ||
Comment 9•23 years ago
|
||
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...
Comment 10•23 years ago
|
||
This be caused by bug 127557. JS errors have their way of stopping script execution and all that...
Comment 11•23 years ago
|
||
(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
Assignee | ||
Comment 12•23 years ago
|
||
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
Comment 13•23 years ago
|
||
2002030206/Linux works fine.
Reporter | ||
Comment 14•23 years ago
|
||
WFM (original reporter) in a new build. Resolving WFM.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•