Closed Bug 128322 Opened 23 years ago Closed 22 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: 22 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: