Closed
Bug 111904
Opened 23 years ago
Closed 22 years ago
"<site> could not be found" dialog on nonresolveable domains for in-page elements
Categories
(Core :: DOM: Navigation, defect)
Core
DOM: Navigation
Tracking
()
Future
People
(Reporter: kmself, Assigned: adamlock)
References
Details
Attachments
(2 files, 1 obsolete file)
358 bytes,
text/html
|
Details | |
1.64 KB,
patch
|
mkaply
:
review+
|
Details | Diff | Splinter Review |
For various reasons a site may choose to declare itself a master authority for certain Internet domains, effectively blackholing all requests which come from the site. When connecting to a page within such a listed domain, Mozilla currently raises a dialog stating that the domain could not be loaded: "<site> could not be found. Please check the name and try again." However, the same dialog is raised if an in-page element (graphics or banners) refers to such a site. In this case, the dialog is likely to be encountered frequently, and is annoying. The dialog is modal: all processing stops for Mozilla until the dialog is dismissed. When opening multiple pages (possible under tabbed browsing with newer versions of Mozilla, or with other Gecko-based browsers such as Skipstone or Galeon), each instance of the dialog must be acknowledged before processing can continue. Suggestions: - Don't raise the dialog for any in-page elements that cannot be resolved. Possibly differentiate between major page elements (eg: frame elements) and other elements (eg: banners or cookie servers). - Raise the dialog for all instances, but provide a checkbox to allow future messages for the same host or domain (or explicitly provide both options) to be ignored. If the conceptualization isn't clear: the specific issue is blackholing advertising sites such as Doubleclick via a DNS blackhole. Other filtering techniques, including Junkbuster, avoid the error, but aren't uniformly available. Reproduction: From a host using a DNS server which is authoritative for, say, doubleclick.net, load a page from a site syndicating ads through Doubleclick. One such page is http://www.theregister.co.uk/ (reload as needed until a Doublecklick ad is served). For instructions on how to enter an authoritative DNS entry for a given site, see: http://zgp.org/pipermail/linux-elitists/2000-April/000340.html Thanks.
Comment 1•23 years ago
|
||
->necko
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → benc
Comment 2•22 years ago
|
||
*** Bug 126906 has been marked as a duplicate of this bug. ***
Comment 3•22 years ago
|
||
This happens on OS/2 as well if you try to use your hosts file to redirect ad servers to 127.0.0.1 when there is no server running. In those cases, the error is "connection refused". Mozilla should not put up any errors for in-page elements at all.
OS: Linux → All
Hardware: Other → All
Comment 4•22 years ago
|
||
2002022816 OS/2 Did someone try to fix this recently? It is now worse. Now when access to an in page element is denied, as soon as the modal dialog is clicked away, focus is shifted away from Mozilla, each and every time the dialog comes up. Good example to test is http://us.imdb.com/search, which pops the ads.doubleclick.net (0.0.0.0 <- ads.doubleclick.net in hosts file) dialog twice per page load.
Comment 5•22 years ago
|
||
2002031916 This bug's severity is wrong. I have to click away the modal dialog 2-3 times on every eBay page only in Mozilla, never in other browsers. Please change. Is: minor Should be: major
Comment 7•22 years ago
|
||
i agree, we shouldn't post these alert boxes for inline content -> docshell adam: all you have to do is test if a nsIChannel has the LOAD_DOCUMENT_URI load flag set. if so, the channel corresponds to a toplevel document. if not, then alert boxes should probably be suppressed.
Assignee: neeti → adamlock
Component: Networking → Embedding: Docshell
QA Contact: benc → adamlock
qa to me. +nsbeta1, mozilla1.0 This should not be happening. Someone please create an example page with lots of non-existent inline links, so the point can be demonstrated. 10 dialogs should be sufficient.
Comment 9•22 years ago
|
||
Shouldn't need a demo page. Just go to http://www.smartin-designs.com/downloads.htm and get one of the adblocker hosts files, unzip it where appropriate, then go to eBay and search for anything, or go to http://www.imdb.com/search/ and do any search. Most results pages will generate at least two warning dialogs. I started using that ad blocking strategy long before my first use of Mozilla. It works fine in Netscape 3. In Netscape 4 it also works, although the timeout period there runs so long that it takes a while for N4 to idle.
Comment 10•22 years ago
|
||
This isn't an acceptable solution to the problem of not-found documents or document elements. See comments added to 28586 for reasons why; I don't want to see a dialog even once on such a minor thing as an unresolvable domain or a black-holed domain, especially since dialogs currently remove and do not restore focus to Mozilla on Win32 (2002031104). I've actually had to start running a webserver on my PC to prevent Mozilla from doing stupid things with this -- this dialog makes Mozilla seem 'less professional' than Internet Explorer because it demands attention when none likely needs be provided.
Assignee | ||
Comment 11•22 years ago
|
||
Testing for nsIChannel::LOAD_DOCUMENT_URI doesn't work as the nsIChannel for the IFRAME has this bit set. Code like this might be more appropriate. PRBool isTopFrame = PR_TRUE; nsCOMPtr<nsIDocShellTreeItem> targetParentTreeItem; rv = GetSameTypeParent(getter_AddRefs(targetParentTreeItem)); if (NS_SUCCEEDED(rv) && targetParentTreeItem) { isTopFrame = PR_FALSE; } However, can I clarify whether we should supress errors on all frames or just iframes?
Comment 12•22 years ago
|
||
mrmazda: I would prefer is someone constructed a URL that demonstrates this. As I have commented elsewhere, people deliberatly hacking up their /etc/hosts file so that they block ads is actually bad system administration. I'm not going to get a lot of converts if I have to ask them to do that to see the bug. (I don't want to debate this hear, just accept it as true). Someone somewhere could care up page full of bad links... Austin: nobody says this fixes the other bug. But if it comes down to fixing only this, or fixing nothing, I'm going to take this fix. BTW, can anyone check Communicator 4, if so this earns a 4xp keyword, and another firm reason to move this up on the priority list.
Assignee | ||
Comment 13•22 years ago
|
||
Attachment 76054 [details] for bug 34943 demonstrates a page with a duff IFRAME. I would still like opinion whether errors should be suppressed for all frames or just IFRAMEs.
Comment 14•22 years ago
|
||
Is a frame an in page element? Then this bug should apply to frames. Before comment #13 I tried to create a testcase page. The result (which does not result in any popups) is at http://mrmazda.members.atlantic.net/junk/unresolvable.html. All it actually does is make Mozilla take a while to idle after not finding the non-existent embedded elements. In order to test it, I had to make unavailable my 10,800 line HOSTS file. The consequence of that is when I use Netscape 3 or Netscape 4 (4xp) I am forced to view unwanted banner ads or add or remove the hosts file each time I switch to a different browser. Using the hosts file to block ads may be a kludge, but it works in Netscape 3, Netscape 4 (4xp), and IE, and is much simpler to administer than installing special software to block ad hosts. At least until Mozilla is competent to fully supplant all of those browsers, Mozilla needs to accomodate use of the hosts file for blocking ads. Another reason it needs to make this accomodation is the clumsy way of adding locations to Mozilla's own blocking database, which currently provides no way to en masse add unwanted hosts. This is easily done with the hosts file by simply downloading a new one provided by someone taking the trouble to maintain it and add new hosts as they appear.
Assignee | ||
Comment 15•22 years ago
|
||
The patch supresses errors on subframes. Patch tests if the docshell has a parent (of the same type), in which case it supresses certain errors. It could also suppress NS_ERROR_FILE_NOT_FOUND but probably shouldn't for loading for loading file: protocol URLs. Neither does it suppress the more esoteric errors NS_ERROR_REDIRECT_LOOP, NS_ERROR_UNKNOWN_SOCKET_TYPE, NS_ERROR_NET_RESET. These occur less frequently so perhaps there is value in displaying them.
Comment 16•22 years ago
|
||
Please, someone create a page that shows all the offending elements. I think you can submit it as an attachment if you do not have a public web server. If people want this fixed, they need to give a clear-cut example of the page elements that matter. This way, Adam will know exactly what you are talking about, and whether or not he has the correct behavior. This is a futured bug, so making this easy for Adam makes it more likely it will be fixed for mozilla 1.0.
Comment 17•22 years ago
|
||
*** Bug 129681 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 18•22 years ago
|
||
This test page demonstrates 2 iframes that currently report errors. Patch follows which supresses those errors.
Attachment #80977 -
Attachment is patch: false
Attachment #80977 -
Attachment mime type: text/plain → text/html
Assignee | ||
Comment 19•22 years ago
|
||
Patch supresses the two principle error messages - site not found & connection refused. I think this would suffice for now unless someone can demonstrate a site that suffers from another kind of error problem. Reviews please.
Attachment #76582 -
Attachment is obsolete: true
Assignee | ||
Comment 20•22 years ago
|
||
Still waiting for a review. This is unlikely to make it into 1.0.
Keywords: review
Comment 21•22 years ago
|
||
I will beg powers that be find a reviewer somehow...
Assignee | ||
Comment 22•22 years ago
|
||
Can someone here please review this? Thanks
Comment 23•22 years ago
|
||
Comment on attachment 80979 [details] [diff] [review] Updated patch r=mkaply Looks good to me.
Attachment #80979 -
Flags: review+
Comment 24•22 years ago
|
||
hey adam, it seems wrong to suppress DNS failures for FRAMESETS and IFRAMES... i agree that throwing a modal message box is unacceptable, but i think that SOME feedback is important... perhaps, we could just load an 'error' page (like IE does) which says that a DNS failure has occurred... This would NOT block the users, but it would provide feedback as to why the content was not loaded... -- rick
Comment 25•22 years ago
|
||
No feedback is necessary regardless of why. If iframes and framesets require special treatment to ensure the user is bothered, then that's the behavior the employers of adservers will switch to.
Comment 26•22 years ago
|
||
displaying a local error page within the offending frame indicating that the content was not loaded due to a DNS failure is NOT special treatment and is NOT exploitable by advertisers. i agree that displaying a modal dialog box is unacceptable. however, providing absolutely NO feedback is unacceptable as well. -- rick
Comment 27•22 years ago
|
||
Useful and well designed sites don't *depend* on content not locally hosted, so offsite stuff should be accorded inferior treatment. Nothing more that completely innocuous should be imposed on the user as a result of such failures. Let's not let whatever that may be prevent the current modal block from being disposed of with the greatest of haste. This (major) bug is much too old to not be fixed already.
Assignee | ||
Comment 28•22 years ago
|
||
Bug 28586 deals with displaying human readable descriptions for errors (like in IE). Perhaps we should go with this patch for now with the expectation that the other will display meaningful errors in frames that don't load.
Comment 29•22 years ago
|
||
> Useful and well designed sites don't *depend* on content not locally hosted, so
> offsite stuff should be accorded inferior treatment.
I'm afraid that i don't agree with this assessment. Providing user-level
feedback about DNS failures for documents is both useful and important in many
situations.
Completely suppressing these notifications just trades one bug for another.
Let's fix this bug the *right* way...
I'm not sure it makes sense to check this patch in... Especially, since the
patch should not be checked into the Mozilla 1.0 branch (because it introduces a
major regression wrt all previous versions of the browser).
-- rick
Updated•22 years ago
|
Depends on: errorpages
Comment 30•22 years ago
|
||
Bug 28586 seems to address the need to provide feedback. This bug seems as much to block that bug than depend on it, and it blocks many. Lets get rid of the inpage modals here ASAP and let 28586 dispose of the feedback issue. This is major and old. It is overdue for resolution.
Comment 31•22 years ago
|
||
I believe that this bug should be dup'ed against bug #28586. And we should focus our efforts on fixing the problem without introducing new regressions. -- rick
Assignee | ||
Comment 32•22 years ago
|
||
Duping *** This bug has been marked as a duplicate of 28586 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Comment 33•22 years ago
|
||
REOPEN: (you can't be a duplicate of a bug you depend on) I think these two are distinct, and this fix is a good partial step to hit some low-hanging fruit. If this is ready to go, I think we should make it happen and see what people say. If they hate it, we'll get MORE bugs. I have a feeling people won't complain that much...
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Comment 34•22 years ago
|
||
My mistake... this bug no longer depends on bug #28586 :-) This bug is a complete subset of bug #28586. Further, this patch introduces a major regression to the product. I think it is perfectly reasonable to deal with the modal dialog boxes for DNS failures *first* when fixing bug #28586. But we need to fix the problem correctly -- not by creating new bugs. -- rick *** This bug has been marked as a duplicate of 28586 ***
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
No longer depends on: errorpages
Resolution: --- → DUPLICATE
Comment 35•22 years ago
|
||
What's the regression? That DNS errors don't pop up? We supress lots of errors (checkloadURI, broken images, etc). Every time we have added more dialogs, we get lots of bugs.
Comment 36•22 years ago
|
||
the regression is that we will display empty windows with no user feedback as to why. i'm not suggesting that we add more dialog boxes. i merely want this bug fixed the 'right way' -- no by introducing empty windows. there is a big difference between supressing errors for inline content and errors for documents (even frame documents). without some kind of feedback, people will not understand why there are big empty boxes in their browser. -- rick
You need to log in
before you can comment on or make changes to this bug.
Description
•