Closed Bug 82236 Opened 23 years ago Closed 23 years ago

In some pages, page changes url to ad url and tries to start downloading

Categories

(Core :: DOM: Navigation, defect, P2)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED WORKSFORME
Milestone:
mozilla1.0

People

(Reporter: mikepinkerton, Assigned: radha)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(3 files)

patch to docshell
3.61 KB, patch
Details | Diff | Splinter Review
remove JS dumps. Send notifications for history loads too.
3.22 KB, patch
Details | Diff | Splinter Review
fix urlbar sideeffects in winEmbed, mfcEmbed and viewer
7.68 KB, text/plain
Details 
- go to http://www.washtech.com/news/media/9947-1.html

notice that the url is now

http://ad.doubleclick.net/adi/wpni.washtech/media;kw=media;pos=bottom;sz=468x60;tile=4;ord=0.615017809286029?

and I get four (!) unknown content type dialogs that all want to start
downloading text/html.

5/22/01 mac build.
Isn't the first part of this related to bug 81769 ?
Yes it is. This was caused by the fix to bug 58906. I know the cause. I'm 
looking in to ways to fix this.
Status: NEW → ASSIGNED
In this bug, I'm not sure what causes the unknown content type dialogs to show 
up. But the urlbar updating with the "doubleclick.net" is caused by the fix for 
bug 58906. 

On builds prior to friday (when 58906 was fixed), the urlbar doesn't update with 
doubleclick.net (ofcourse), but the throbber keeps going well after the page is 
completely loaded, with message, "Resolving host washingtonpost.com" in the 
status bar and the progressmeter 80% done, until I press "stop". This was on 
windows.
radha, don't forget to remove the dumps in the JS before you check it in. does 
this address only the urlbar switching to an iframe's document, or does it also 
the download dialogs that occur?

I'll take care of the dumps. I'm not sure what causes the download dialogs. I'm 
investigating it. Backing out my checkin for bug 56062 did not make the dialogs 
go away. Also, mozilla most of the time crashes (in windows and linux) in this 
page, after it has loaded the ads in the subframes. 
is it the same crash as in 82233?

*** Bug 81769 has been marked as a duplicate of this bug. ***
The latest patch includes fixes for viewer, winEmbed and mfcEmbed so that these 
popular embedding applications do not update the urlbar for a subframe 
navigation. Basically the patch to nsBrowserStatushandler.js was repeated on 
these popular embeddors. I will send a email to owners of other embedding 
applications, that may need a similar patch.
nominating for 0.9.1
Keywords: mozilla0.9.1
*** Bug 82856 has been marked as a duplicate of this bug. ***
Platform/OS All/All.
OS: Mac System 9.x → All
Hardware: Macintosh → All
There's 10 dups of bug 81769. This should be mostfreq.
Adding mostfreq keyword, you are correct. Also adding jrgm's status whiteboard
from there - critical for mozilla 0.9.1.
Keywords: mostfreq
Whiteboard: critical for mozilla 0.9.1
*** Bug 82922 has been marked as a duplicate of this bug. ***
For the download dialogs: I do not see this with the patch to bug 80313
applied. Url is still changed to the ad url however.

*** Bug 82937 has been marked as a duplicate of this bug. ***
*** Bug 82943 has been marked as a duplicate of this bug. ***
in bug 82079 d/l weirdness is triggered by closing a window 
*** Bug 83043 has been marked as a duplicate of this bug. ***
*** Bug 83062 has been marked as a duplicate of this bug. ***
radha, what's the status of this bug? I am getting MANY duplicate bugs filed
against me (see above), and it's getting a little frustrating.. does this need
reviewers? Approval?
r=valeski on the 05/25/01 16:59 patch.
cool, looks ok to me.. seems like we could avoid checking for the subframe
situation by returning early from the root document check..save ourselves the QI

but if you don't want to change that (i.e. makes more sense in the context of
other code in this file) that's fine

sr=alecf with or without that change
Priority: -- → P1
Whiteboard: critical for mozilla 0.9.1 → critical for mozilla 0.9.1, need approval
Target Milestone: --- → mozilla0.9.1
a=blizzard for 0.9.1
fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 83043 has been marked as a duplicate of this bug. ***
*** Bug 83307 has been marked as a duplicate of this bug. ***
*** Bug 83296 has been marked as a duplicate of this bug. ***
I verified fix in 2001053008/Linux.
Just tried Win32 build 2001053004 and the problem still happens occasionally. Go to http://www.anandtech.com and try reading any review article that has several pages. Click successively thru several pages and then rapidly click Back several times then overclick as fast as you can forward again. Occasionally it will not show the correct final URL. Instead it will show an advertisement URL. If you click thru all of one article and then click on the add to the Mushkin DDR site (which is currently on just about all their pages so its easy to find) then back all the way up and then overclick quickly forward you may see it that way as well.

Also, I installed the 2001-05-30-09-trunk sea talkback exe and still saw this problem again on that build as well. But its rare and to make it happen appears to require being able to click ahead faster than the browser can respond so that more Forward clicks get sent than there are pages to advance to.
Yes, I can also see the urlbar be updated with the url of a iframe ad banner
when doing Back and Forward at http://www.anandtech.com/ (win2k 2001053004).

And, I can also be on occasion prompted to download the contents of an iframe
ad banner when I go clicking around the links at the originally reported site 
for this bug report (http://www.washtech.com/news/media/9947-1.html).

The most glaring aspect (just visit any page with an iframe and have the urlbar
be overwritten with iframe URL) appears to be fixed. But these other aspects
are still visible. Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Resummarising. I don't think it is critical to 0.9.1 anymore. I'm not sure what 
triggers the download of the ad banners. I will have to investigate that.
Severity: critical → normal
Status: REOPENED → ASSIGNED
Keywords: mozilla0.9.1, nsbeta1, nsmac1
Priority: P1 → P2
Summary: page changes url to ad url and tries to start downloading → In some pages, page changes url to ad url and tries to start downloading
Whiteboard: critical for mozilla 0.9.1, need approval
Target Milestone: mozilla0.9.1 → mozilla1.0
Radha, I don't know how these bugs got to different audiences but this bug
and bug 81576(nsbeta1+, moz 0.9.1) seem to revolve around the same issue and it
looks like Bill Law has made some progress on it, maybe you should take a look
at that, there may be some info to share or duplication of effort to save.
in the 5/30/01 mac build, i got the download dialog visiting www.cnn.com trying
to d/l a mimetype of text/html.
cc'ing Bill Law. Maybe the download of ads is related to his bug 81576. Bill,
Where is the unknown content type dialog triggered from? I want to check if my
changes to onLocationChange() has anything to do with these dialogs showing up
in random. 
I don't always get the download dialog on CNN, but (at least so far), I've
gotten multiples of them each time I visit this site:
http://www.mangazoo.com/maniax/index.html, in case that helps.
*** Bug 83641 has been marked as a duplicate of this bug. ***
Thanks, Radha, but you are too kind to make bug 81576 "my" bug.  It just happens
to be assigned to me until I can find the rightful ownwer :-).

The dialog appears downstream from nsExternalHelperAppService::DoContent
(http://lxr.mozilla.org/seamonkey/source/uriloader/exthandler/nsExternalHelperAppService.cpp#222).
 The dialog appears when the stream listener gets OnStartRequest (in that same
file) but that's probably not what you're really interested in.  DoContent is
called from nsDocumentOpenInfo::DispatchContent
(http://lxr.mozilla.org/seamonkey/source/uriloader/base/nsURILoader.cpp#364).
That seems to be the point at which we decide that we can't load the content in
the docshell in which it "originated."

There may be other places, though.  I don't fully grok the uriloader.
I noticed that the urls described at the beginning of this bug report are
doubleclick.net ads.  Bug 81576 involves similar content, which may not be a
coincidence.

Try adding the "!mBody" checks as described in that bug and see if it clears
this one up (I haven't tried that at cbs.marketwatch.com yet, but am working on
that right now).
*** Bug 83793 has been marked as a duplicate of this bug. ***
steps to reproduce (tested in #mozillazine)

1. open www.funweb.de
2. click login
3. enter testuser/dogyou19
have to choose a chat channel
there's a box called chat-channel
choose one, eg. fun-web

2 of the frames will be offered for download
Hi,

Can someone clarify? Does the URL change AND the download box appear for ALL
reports, and more importantly, is this really the same problem?

I got a couple of these reports inside the networking component. If we need to
change component (is this really "History"?!), let me know.
On
http://canoe.clicktv.com/listings.asp?profileID=%2477%2478%2490%247A%2492%248C&cid=097&rcookme=1&UserID=%2476%247A%248A%2471%2489%248A
Only the download box appears, it doesnt change the URL: in the urlbar...

Btw, I am blocking all the ads on that page, but the banner at the top of the
page is still loaded. Even if the option to block it isnt in the right-click
menu... I dont know if that's linked or not. I also dont know if it will work
for you because I have a cookie for that site (with my prefs)...
The urlbar updating problem, and the download dialog problem, can happen 
independently. bug 81769 was originally filed just for the url update problem.

I'm seeing similar behavior, that looks like a race condition, somewhere.  My
home page is a local CGI, which sends an HTTP Refresh: header to itself with an
extra argument.  I.E. the home page in mozilla is set to
http://localhost/cgi-bin/foo, running that sends a "Refresh: 0;
url=http://localhost/cgi-bin/foo?bar=foobaz" header back to Mozilla, and loading
that brings up the page.  The page is a frameset with two frames, each frame is
the same cgi-bin app, with other argument.

Each time I open a new mozilla window, there's about a 50-50% chance that I will
get a ``You have chosen to download a file of type: "Hypertext Markup Language"
[text/html] from http://localhost/cgi-bin/'' dialog.  That's exactly what the
dialog says, the URL gets chopped off at the cgi-bin part (the usual "use
default action/different action" selection follow beneath).  About 10% of the
time I get two of these suckers to pop up at the same time (!).  Note that the
main mozilla window stills loads and correctly displays the home page content,
produced by the cgi-bin app.

The dialogs appear to be complete duds.  Selecting "save to disk" makes the
dialog boxes disappear forever, without even a filename prompt.

Last daily build I used was from April, and did not exhibit this behavior.  The
build I'm seeing this behavior is 2001060414.

This appears to be a race condition somewhere for the following reasons:

* The cgi app is a executable binary on the local machine, that runs and
terminates very quickly.  I could not reproduce this behavior with a more
heavyweight CGI perl script that pushes the same exact HTTP headers+content back
to Mozilla.  Also I could not reproduce this behavior running the same CGI over
a network, with a comparatively larger latency.  The trick is to have Mozilla
either simultaneously or consecutively issue multiple http requests for a new
window, as quickly as possible.

* The dud dialogs pop up only about 50% of the time, at random.

We need to add simillar patch as the 05/25/01 16:59 to gtkembed too. I've filed
a new bug 84612 on this.
Depends on: 84612
Another testcase this is not an ad either:

1) Goto http://lrp.steinkuehler.net/DiskImages/Eiger/EigerStein.htm

2) Click on Step-by-Step instructions (under HOWTO)

You get download box for Application/octet-stream when its just a textfile. NN4
& IE handle this fine.
Last comment: Isn't that a server misconfiguration?
*** Bug 84154 has been marked as a duplicate of this bug. ***
ksosez: <http://lrp.steinkuehler.net/files/diskimages/eiger/EigerStein.readme>
works for me. File is sent as text/plain and displayed properly in 2001081003
Win98. This may have been fixed either on the server side or in the browser
since your comments were filed.
I can't reproduce this bug with its original url and in other probable links
provided in the report.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → WORKSFORME
Yeah, this all better now, as far as I've seen.
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: