Closed Bug 128322 Opened 23 years ago Closed 23 years ago

History Sidebar opens topmost visible link automatically

Categories

(Core Graveyard :: History: Global, defect, P2)

Product:
Core Graveyard
Component:
History: Global
Platform:
x86
Windows 98
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: bugzilla, Assigned: bugzilla)

References

Details

(Whiteboard: [adt2 rtm])

Attachments

(1 file, 1 obsolete file)

patch
933 bytes, patch
andreww
: review+
hewitt
: superreview+
Details | Diff | Splinter Review
Ever since the history sidebar was changed so that links work on a single -click I have had the following problems. (Currently using 2002022603.) 1. Set history to Group By None. 2. Open history on sidebar. Topmost link opens without clicking. 3. Navigate somewhere else with sidebar still open. Previously automagically opened page immediately opens again. 4. Navigating back loads the desired page. 5. Navigate yet somewhere else. Same page opens all by itself. Group by Day also exhibits the latter behavior after clicking history link if the next page you navigate to (in step 3) appears within the open twistie. (ie Navigate within a site after first getting there from history.) Closing the history sidebar panel seems to cancel the effect. I think two things are wrong here. 1. Opening the panel with Group by None activates the topmost link. 2. Regardless of Group by, once a link is activated (either automatically or by clicking) it reloads itself everytime a new history item is added due to navigation.
Further testing shows that repeat loading behavior definitely only occurs if the new page you navigate to changes the history display. If it is already in the history the problem doesn't occur.
using winme with moz1rc1. confirmed, same thing seen. major annoyance. this should be shifted to severity major, like bug #132792. suggest keyword "regression".
I noticed this problem as well on OpenVMS 20020419: Whenever I clicked on history tab on the side panel, I went to the top most bookmark. However, I also noticed: This was not a problem if I clicked on go|History If I set my history "group by" to "Day" (go|history|view|group by) this problem does not occur.
*** This bug has been confirmed by popular vote. ***
Status: UNCONFIRMED → NEW
Ever confirmed: true
Confirmed on Win2K and Linux. Agree that this is a *major* annoyance. Suggest changing the priority. Should be a 1.0 fix with greater severity.
Still a problem with OpenVMS build 20020513 (rc2)
I see something very similar - selecting the History sidebar tab, or opening a new window when the History sidebar is selected, causes the browser to open URL find:datasource=history&match=AgeInDays&method=is&text=0&groupby=Hostname Now due to a bug in handling the find: method, Moz tries to open www.find.com which redirects to http://apps5.oingo.com/apps/domainpark/domainpark.cgi?s=find&dp_lp=7&cid=GOTO6262&dp_format=1.3&dp_p4pid=idealab&dp_own=Idealab&dp_cm=_b&dp_c1=000099 1.0 RC3, W2K.
nsbeta1, p2, target mozilla1.0
Keywords: nsbeta1
Priority: -- → P2
Target Milestone: --- → mozilla1.0
"oingo" is bug 146619 for now
This looks like a regression of the single-click history fix.
i think this bug now triggers a pageload when mailnews is started even with sidebar closed IF history is the tab that is displayed when sidebar opens: bug 147335 Other bugs in the family are: bug 132792, bug 147176, bug 107966, bug 140797, bug 143707 but they may all boil down to this one..
Nav triage team: nsbeta1+, adt2 rtm
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [adt2 rtm]
Up the severity dudes, this is rather embarrasing for 1.0 :(
Severity: normal → major
The severity is already higher than I think it should be, since there is no 'major loss of function' here.
Sounds like something to add to the "make 1.0.1 not suck" list. Probably too late for 1.0...
Attached patch patch — — Splinter Review
cc'ing ben for review.
Comment on attachment 85613 [details] [diff] [review] patch r=andreww
Attachment #85613 - Flags: review+
Remarks re. comment #14 above, "there is no 'major loss of function' here.": At least three major functional problems: 1) However the content of the history sidebar may be grouped, if the history sidebar was exposed the last time Mozilla shut down, then clicking on any link in subsequent invocations of mozilla (browser or mailnews) does not load the desired page, but the "http://find" (or however the browser resolves the bogus URL). Certainly there are partial workarounds (copy the proper URL to the navigation toolbar, etc.), but what's the point then of developing an integrated browser/communications suite of programs? 2) If the browser gets into the state where the same page is loaded no matter what page a link references, and the users are constantly obliged to use the back-button to reach the actual page they clicked on, is this really a *minor* degradation of functionality? 3) The behaviour referenced in this bug (and the others referenced here) make it impossible for people to designate Mozilla as the default browser for the content types it supports, since *only* the bogus page will open. Some "minor" loss of function! An earlier comment alluded to the possibility that the sudden appearance of these bugs may be related to users no longer having to double click on history sidebar entries. How difficult is it to back out such change(s) and test the hypothesis? I don't have the knowledge of Mozilla internals, etc., to do this myself. (Nor is doubleclicking on a history entry such a problem for most users--but perhaps this marks me as an antique, since I deliberately disable such features on MS Windows as "Active Desktop", one-click file opening, etc., so I'm not in a good position to judge UI preferences.) Presumably Netscape's recent preview release based on RC2 does not have this set of bugs--maybe someone with access to their branch of the session history code can determine what the significant differences are that may relate to this bug, and work out a patch. Sorry about the tone of this comment; I know mozilla is experimental and beta code by nature, but I don't think underplaying these bugs in a release candidate gets the project anywhere; untended, these kinds of regressions will work their way into the DNA of the giant lizard, who will meet the fate of the dinosaurs...
'Loss of function' means something that you were able to do that is now impossible. This is a defect, and it is annoying, and we do want to fix it for the release, but there is only loss of access in one specific scenario; for which there are workarounds. You can still browse, use history, etc. That's all I meant. Overplaying these bugs is also bad, as it takes focus off higher priorities, such as features that may really be broken.
Comment on attachment 85613 [details] [diff] [review] patch sr=hewitt
Attachment #85613 - Flags: superreview+
(That |return| is extraneous and can be removed.)
Keywords: adt1.0.1
*** Bug 132792 has been marked as a duplicate of this bug. ***
I tried that patch (on trunk and branch) and although it is better now I still get the find-call when opening a folder in history.
Blake, does that patch meet with your approval?
RE: comment #20. I went overboard in my comments, and I appreciate the call to moderation. However, I would still classify all the misbehaviours I mentioned as truly broken functions: after all, wrong or inexistant pages are loaded in place of the right ones, for which the workaround may be not to keep the history sidebar open while using the browser, but people facing this peculiar browser misbehaviour will have a devil of a time finding out how to circumvent it. And it is a major usability defect.
Windows BUILD 2002053012 HISTORY SIDEBAR MAJOR DEFECTS. 1. Opening History Sidebar defaults on Today, starts "resolving host find" 2. Clicking on *any* folder (Today, somesite.com, etc) starts "resolving host find" I hope for everyones sake that the parked host 'find' doesn't become a pornography site (or worse)... fix for 1.0 !!! Not later.
bug 140009 is now the AB variant of this
*** Bug 146619 has been marked as a duplicate of this bug. ***
RE: comment #25 Works fine. I patched the file and tested it with Build 2002060208 WinXP.
*** Bug 148688 has been marked as a duplicate of this bug. ***
Comment on attachment 85755 [details] [diff] [review] Patch that should also stops folders opening sr=blake, looks good. noting joe's r.
Attachment #85755 - Attachment is obsolete: true
Attachment #85755 - Flags: superreview+
Attachment #85755 - Flags: review+
Fixed on trunk.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 149088 has been marked as a duplicate of this bug. ***
*** Bug 148942 has been marked as a duplicate of this bug. ***
heh, the comment starting at line 123 of history.js is out of date :-)
*** Bug 140797 has been marked as a duplicate of this bug. ***
Well, it seems that this but is not fixed in Mozilla 1.0. Maybe the status should not be FIXED.
*** Bug 149287 has been marked as a duplicate of this bug. ***
*** Bug 147844 has been marked as a duplicate of this bug. ***
*** Bug 149486 has been marked as a duplicate of this bug. ***
*** Bug 149405 has been marked as a duplicate of this bug. ***
*** Bug 149487 has been marked as a duplicate of this bug. ***
ADT1.0.1+ per ADT, okay to land on branch once you have Driver's approval.
Keywords: adt1.0.1 → adt1.0.1+
*** Bug 149650 has been marked as a duplicate of this bug. ***
I think the patch 05/30/02 should be modified, as clicking on the "twisty" still loads the find.com page after that patch. Here is my suggestion (ie. works for me) + else if ( elt.value != "twisty" ) { + OpenURL(false); + return; + }
*** Bug 149684 has been marked as a duplicate of this bug. ***
I'm using the simple fix in http://bugzilla.mozilla.org/show_bug.cgi?id=146619#c27 but only on Mozilla 1.0 release; appears to work fine, no regression to loading http://find no matter what I try. Is this fix too simple?
*** Bug 149851 has been marked as a duplicate of this bug. ***
Although it might appear otherwise it looks as if my 05/31/02 patch got checked in, not the 05/30/02 patch that as sam verified doesn't work.
please checkin to the 1.0.1 branch. once there remove the "mozilla1.0.1+" keyword and add the "fixed1.0.1" keyword.
Keywords: mozilla1.0.1+
Comment on attachment 85755 [details] [diff] [review] Patch that should also stops folders opening please check into the 1.0.1 branch ASAP. once landed remove the mozilla1.0.1+ keyword and add the fixed1.0.1 keyword Approving this one because it appears to be the one checked in
Attachment #85755 - Flags: approval+
*** Bug 150397 has been marked as a duplicate of this bug. ***
You may be interested to know that there is a workaround for this bug: 1. Use CTRL-H to open the history window. 2. Select the option in the follwoing menu tree View->Group By->None 3. Close the history window. There will no longer be a tree in your history window. The bug no long appears.
*** Bug 150701 has been marked as a duplicate of this bug. ***
Please check this into the branch asap. If it was already checked in, please add fixed1.0.1.
*** Bug 151115 has been marked as a duplicate of this bug. ***
This hasn't made it on the branch!
Keywords: mozilla1.0.1+ → fixed1.0.1
*** Bug 153095 has been marked as a duplicate of this bug. ***
*** Bug 153934 has been marked as a duplicate of this bug. ***
this bug may have set some sort of record for dupes and dupes of dupes across numerous components. VERIFIED Fixed on 20020627 branch and trunk builds
Status: RESOLVED → VERIFIED
Keywords: fixed1.0.1 → verified1.0.1
*** Bug 155361 has been marked as a duplicate of this bug. ***
*** Bug 155399 has been marked as a duplicate of this bug. ***
*** Bug 156005 has been marked as a duplicate of this bug. ***
*** Bug 156059 has been marked as a duplicate of this bug. ***
*** Bug 151015 has been marked as a duplicate of this bug. ***
*** Bug 157076 has been marked as a duplicate of this bug. ***
*** Bug 158585 has been marked as a duplicate of this bug. ***
I see that this bug is generally fixed, but if I click on a column header to re-sort my history in the sidebar, the new top link is automatically opened. Is there another bug for this?
Okay, I'm using winxp, build 072108. I have history set to Group by > none. In the sidebar, I have the title and last visited columns displayed. I open the sidebar, click on the last visited column header to re-sort the entries, and the topmost link is browsed to. If I click on the header again, the new topmost link is browsed to.
I'm also seeing that also on Windows 98, 1.1 trunk 2002071914. It looks like that is bug 151024. Let's take this discussion over to that bug.
*** Bug 158721 has been marked as a duplicate of this bug. ***
*** Bug 159449 has been marked as a duplicate of this bug. ***
*** Bug 159740 has been marked as a duplicate of this bug. ***
*** Bug 159758 has been marked as a duplicate of this bug. ***
*** Bug 162372 has been marked as a duplicate of this bug. ***
*** Bug 163860 has been marked as a duplicate of this bug. ***
*** Bug 164000 has been marked as a duplicate of this bug. ***
*** Bug 167743 has been marked as a duplicate of this bug. ***
*** Bug 167797 has been marked as a duplicate of this bug. ***
*** Bug 175995 has been marked as a duplicate of this bug. ***
*** Bug 163965 has been marked as a duplicate of this bug. ***
*** Bug 230418 has been marked as a duplicate of this bug. ***
*** Bug 164721 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: