Closed Bug 146619 Opened 22 years ago Closed 22 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: 22 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.