Closed Bug 82236 Opened 24 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: 24 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: 24 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: