Closed Bug 146619 Opened 24 years ago Closed 24 years ago

history sidebar when focused on something other than a url loads a find.homepage (oingo.com)

Categories

(Core Graveyard :: History: Global, defect)

Product:
Core Graveyard
Component:
History: Global
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 128322

People

(Reporter: noel.clarkson, Assigned: bugzilla)

References

Details

(Keywords: regression)

RC3 when focusing on the today folder to domain name folders in the history sidebar trys to show http://find.my_default_homepage/ Reproducible: Always Steps to Reproduce: 1.Click on a folder in the histopry tab or 2.Start mozilla up with the history tab on top 3. Actual Results: Trys to show non existant find.my_default_homepage Expected Results: Not to load anything
related: bug 143707, bug 140797, bug 145521 Seeing this too, with a current cvs build, linux. Very annoying. This bug also means that either an unwanted page loads, or an error message will be spawned each time browser is started with history sidebar open. If you can't trigger it at once: Just write "find" in urlbar and hit enter. "find" will then land in history, and after this the bug spawns each time. severity up, resolution new, nominating for 1.0 and over to sidebar
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Browser-General → Sidebar
Ever confirmed: true
Keywords: mozilla1.0
.
Assignee: Matti → sgehani
QA Contact: imajes-qa → sujay
--> history
Assignee: sgehani → blaker
Component: Sidebar → History: Global
QA Contact: sujay → claudius
See my messages snews://secnews.netscape.com:563/3CEF12A6.2040807@xxx.xxx and snews://secnews.netscape.com:563/3CEF1D0E.1060109@xxx.xxx on this problem. If the browser is set to show the history sidebar when launched, then clicking (and the RMB "Open in new Window" menu item) on any URL in MailNews launches the browser trying to connect to http://find/ This effectively destroys a useful feature of Mozilla (or any other browser). This bug should be marked a blocker for Mozilla 1.0: please!!! Michel.
*** Bug 146987 has been marked as a duplicate of this bug. ***
Apologies for the excited tone in my comment above; the bug is a very annoying regression, but not the end of world (or Mozilla).
O.K. http://bugzilla.mozilla.org/show_bug.cgi?id=128322 seems to be similar to this, but history must be grouped by day in order for the bug to show: browse any page in your History Sidebar, then click on a site-name or day in the sidebar, and the the browser starts loading http://find
*** Bug 147250 has been marked as a duplicate of this bug. ***
see also bug 147176. Clicking anything (right or left-click) in sidebar history trigger pageloads
OS: Windows 98 → All
This has been building up for quite a while: the new element is loading "find" but similar reports are bug 128322, bug 132792 It also strikes in mailnews: bug 107966, bug 140797, bug 143707
I have noticed that after the browser can't fined find (for me it trys to go to just http://find it goes to http://apps5.oingo.com . I find this to be really annoying.
*** Bug 147526 has been marked as a duplicate of this bug. ***
*** Bug 147618 has been marked as a duplicate of this bug. ***
*** Bug 147637 has been marked as a duplicate of this bug. ***
on win me 2002052404 build every time I click the history tab - searches for "find" using nbt then dns (www.find.com) then redirects to http://apps5.oingo.com. most annoying!
Nominating. This sends you to a random site when you click a folder in the history sidebar. I'd nominate for beta2 if such a keyword existed.
Keywords: adt1.0.0
Removing adt1.0.0 and adding nsbeta1. Sfendiing back to the nav triage team to triage.
Keywords: adt1.0.0 → nsbeta1
blaker, Is this a dupe of nsbeta1+ bug 128322? If so, please mark it as such to get it off the radar. Thanks. -- nav triage team
*** Bug 147989 has been marked as a duplicate of this bug. ***
Fwiw, I never saw this bug until RC3 (history tab clicks eventually leading to oingo) & now I see it every time I use the history sidebar.
*** Bug 148198 has been marked as a duplicate of this bug. ***
I also never saw this behaviour until RC3 (since 0.9.7), but now I get it gets me after I've been browsing for awhile, every time I click Search.
Summary: history sidebar when focused on something other than a url loads a find.homepage → history sidebar when focused on something other than a url loads a find.homepage (oingo.com)
Windows, build 2002053012. Still seeing this bug. VERY ANNOYING. I know i'm a lonely and unimportant mozilla cheerleader, but seriously... do the developers of this product not use the history sidebar? This bug renders the history sidebar useless. My only hope is that some pornographer takes control of the under construction site so that people are redirected to unwanted smut and the complaints get loud enough so that this bug gets the attention it deserves.
*** Bug 147176 has been marked as a duplicate of this bug. ***
Just to summarize, Mozilla tries to go to http://find.com. That redirects to http://apps5.oingo.com. This is a regression.
Keywords: regression
Part of this "hypersensitive" sidebar history problem is that: -Switching to history tab (by click or menu) triggers the bogus "find" -Single left click triggers "find" when clicking "Today", "Yesterday" folder etc. -Both left and right click trigger "find" when clicking subfolders (should do nothing) -Both left and right click triggers pageload when clicking an actual URL in history (should only trigger on left click, and show context on right) This is also a dataloss bug: If i attempt to browse history sidebar while on a "nocache" page with forms, i'll loose what i typed there. Which actually happened to me yesterday. And if i "open frame in new window" with history sidebar is open - it's opening to apps.oingo5.com instead of the page i wanted.
FIX! FIX! FIX! FIX! FIX! FIX! FIX! FIX! FIX! (using build 2002052306, sorry, i don't know how to use CVS.) Impact == Zero. PUT IN MOZ 1.0 PLEASE !!! After much bitching from me, i got off my ass and learned what the hell a jar file is. Took me a while to trace what the hell was going on but essentially, after avoiding several if/else statements, openTopWin() ends up being called without every checking to see if calling object is a container. -=-=-=-=-=-=-=-= comm.jar /content/communicator/history/history.js line 299 OLD: openTopWin(url); NEW: if (isContainer(gHistoryTree, currentIndex) != true) { openTopWin(url); }
Dac: the code for 1.0 has already been tagged and, as I understand it, it is pretty certain that it will be released as it is. There is already patch which fixes this problem attached to bug 128322, and that looks like it will get into 1.0.1, which will be 1.0 with a few small fixes. I guess this bug should be marked to depend on bug 128322, along with a number of other bugs which are symptoms of the same thing, and will be fixed by the same patch...
Resolving as duplicate. *** This bug has been marked as a duplicate of 128322 ***
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → DUPLICATE
michael lefevre: Thanks. Sorry for the trouble. The other patch mentioned in your note looks solid. At least i learned how to debug and make my own changes... :)
*** Bug 149067 has been marked as a duplicate of this bug. ***
This bug is still present in version 1.0 final (june 05/2002) build 2002053012 even after un-installing mozilla completely deleting the folder then re- installing, it still tries to access find.com when opening the history tab winXPP
*** Bug 152378 has been marked as a duplicate of this bug. ***
VERIFIED Dupe
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.