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)

defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 28586
Future

People

(Reporter: kmself, Assigned: adamlock)

References

Details

Attachments

(2 files, 1 obsolete file)

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.
->necko
Assignee: asa → neeti
Status: UNCONFIRMED → NEW
Component: Browser-General → Networking
Ever confirmed: true
QA Contact: doronr → benc
Target Milestone: --- → Future
*** Bug 126906 has been marked as a duplicate of this bug. ***
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
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.
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
cc'ing darin
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.
Severity: minor → major
Keywords: mozilla1.0, nsbeta1
QA Contact: adamlock → benc
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.
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.
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?
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.
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. 
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.
Attached patch Patch (obsolete) — Splinter Review
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.
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.
*** Bug 129681 has been marked as a duplicate of this bug. ***
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
Attached patch Updated patchSplinter Review
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
Still waiting for a review. This is unlikely to make it into 1.0.
Keywords: review
I will beg powers that be find a reviewer somehow...
Can someone here please review this? Thanks
Comment on attachment 80979 [details] [diff] [review]
Updated patch

r=mkaply

Looks good to me.
Attachment #80979 - Flags: review+
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
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.
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
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.
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.
> 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
Depends on: errorpages
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.
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
Duping

*** This bug has been marked as a duplicate of 28586 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
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 → ---
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 ago22 years ago
No longer depends on: errorpages
Resolution: --- → DUPLICATE
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.
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.

Attachment

General

Creator:
Created:
Updated:
Size: