45421 - Offline: No feedback when browsing to an uncached URL in offline mode

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Judson Valeski]

when in offline mode I typed a url into the url bar and clicked on a bookmark 
link. I expected a dialog to come up telling me that I was in offline more but I 
didn't get one.

Comment 1

[Doron Rosenberg (IBM)]

networking issue, moving to it and setting default qa contact.

Comment 2

[selmer (gone)]

Somehow, I'm still the owner of this bug.  Assigning to component owner.

Comment 3

[Stephan Niemz]

Here is another way to see this: load some page in the browser, switch to
offline mode, then middle-click (UNIX) or Ctrl-Click (Windoze) on some link.
A new browser window opens as expected, but it is empty and the Location bar
is also empty! No error message or popup telling me what's wrong.

Expected:
1. Mozilla gives me some hint why it can't load the page
2. the Location bar shows the selected URL, so I can hit Reload after going
   online again.

Changing Platform/OS to all because this isn't Windows specific.
And could anybody please tell me why this is marked "future"? I find this
somewhat annoying.

If the Location bar thing is a different issue, please tell me and I'm opening
a new bug for it.

Comment 4

[Darin Fisher]

Still seeing this in linux build 2000112812.

Comment 5

[Matthew T (active 1999-2002)]

This is major. I don't regard myself as dumb; but several times recently when 
I've been in offline mode, and have forgotten that I'm in offline mode, I have 
come to the erroneous conclusion that Mozilla *isn't working at all* -- I enter 
an address into the address field (or click on a link in a Web page), and 
nothing happens.

I suggest that instead of displaying an alert, a placeholder page be shown 
explaining that the requested resource is not available offline and that 
choosing `Reload' will go online to get it. (See also bug 28586.) This will 
help handle the following cases in offline mode:
*   you're trying to use Alt+Left to browse past an uncached page back to a
    cached one (an alert wouldn't let you past);
*   you're viewing a cached page containing uncached images (a deluge of alerts
    would be annoying).

Comment 6

[Darin Fisher]

agreed.

Comment 7

[[e-mail]]

Console shows:
Error loading URL http://www.imdb.com/ : 2152398864

Comment 8

[benc]

qa to me.
nominating nsbeta1, nscatfood.

See mpt's comments as to why.

Comment 9

[Alex Bishop]

When browsing in offline mode, IE doesn't just tell you when a page isn't
available offline when you follow the link, it actually tells you beforehand by
changing the cursor to a hand with a 'no' symbol next to it (screenshot in
attachment 41992 [details] from bug 48845). This is very useful as you can mouse around a
cached page and see which links are also cached. It would be good if Mozilla did
something similar.

Comment 10

[benc]

I've looked at this in NS 6.1 RTM, and it still gives no errors. Probably
another example of bug 19073.

In-window browsing is deaf to the network.
New window browsing open a blank screen "about:blank" at the bottom.

Also, re-load and shift-reload don't help w/ the blank new windows, you have to
hit enter in the URL bar. (should I file a new bug  for this?

Comment 11

[Alex Bishop]

Correcting summary typo.

Comment 12

[Russell Odom]

I think this should be in 1.0 for the exactly the reasons mpt gave in comment 5
- we can't have a 1.0 product that appears to just stop working!

Also marking 4xp, since (IIRC - correct me if I'm wrong) 4.x showed an alert
under these conditions (although I think mpt's idea of a placeholder page is
better).

Comment 13

[benc]

This may not be fixed for 1.0. Offline browsing is neither a high priority, nor
is it very robust in related areas right now. In the larger picture, we have
more important connectivity issues to address and more important error messages
to fix.

Gagan: Recentlly similar "Networking issues" were assigned to docshell and
fixed. Can you confirm you want Necko to own this problem?

Comment 14

[Ben Bucksch (:BenB)]

> Offline browsing is neither a high priority, nor
> is it very robust in related areas right now.

You are missing the point. The problem are users who activate offline without
realizing it, thinking the app were broken because they can't fetch data anymore.

Comment 15

[benc]

I realize what this bug is about. But compared to other error-message bugs,
there aren't many dupes, and although I feel offline should have landed with
more completeness, we don't persist the offline state, so if you quit, the
problem goes away.

Meanwhile, we continue to get more and more duplicates of the "Mozilla goes deaf
after network changes" bugs.

The UI is pretty obscure, so the chance of someone hitting offline accidentally
and not figuring it out is very low. I think I used Communicator for 2 years
before I realized what it was. It looks like welded pipe to me.

(This reminds me of a joke my high school's football coach said one year. We
were school of 800 in the 1000-5000 student division. He said "we are small, but
we make up for it by being slow").

Enough banter. The only technical issue at hand is "is this the right
component?"  Gagan will be able to answer that. If this is the wrong component,
we can type comments until the database fills up, and it will never be fixed. If
this goes to docshell, then you have found the right audience, and you can make
your case to that coder (who actually have been fixing a bunch of networking
error bugs lately).

Comment 16

[Matthias Versen [:Matti]]

*** Bug 150486 has been marked as a duplicate of this bug. ***

Comment 17

[Christophe Thalet]

the issue is simply:

do not default to about:blank but to about:offline or something in this case

should not be too difficult

Comment 18

[Martin Sch]

Very bad thing!
Accidently went offline and thought something was broken because nothing loaded
any more. 
Deleted all my cache, deleted the history, still no page loaded.
Called the people managing the proxy...nothing.

Then I found the offline icon...

Comment 19

[Rob North]

I encounter only 2 annoying bugs daily.
The most visible is bug 128322.
This bug is the second most.

Matthew Thomas had a point, when relating this problem to the bug 28586,
but I suspect that a dialog box may be more appropriate in this case.

I believe this bug should be fixed in some simple form in mozilla 1.0.1

Please fix soon.

Comment 20

[Brant Gurganus]

At a minimum, we should get a redirection to an error at about:offline or
something similar.  Then, depending on preferences of the user, we should be
prompted to go online.

Comment 21

[Darin Fisher]

-> me

Comment 22

[José Jeria]

Is bug 113591 a dupe of this one?

Comment 23

[benc]

Bug 113591 #18 is probably correct.

Comment 24

[tloehnert]

in relation to this I would like to point out that the message box
"server xyz could not be found ..." that appears if the browser is
in "online" mode but no internet connection is present is not 
too ergonomic also: you have to click on an extra button; a hint in
staus bar or main window would be sufficient

my suggestion: handle this as a whole complex:

-> automatic online/offline detection
-> offline functionality

Comment 25

[Darin Fisher]

Attachment: v1 patch

Comment 26

[Darin Fisher]

this patch makes it so that NS_ERROR_DOCUMENT_NOT_CACHED will be error status of
the channel when offline and the request cannot be satisfied via the cache.

Comment 27

[Adam Lock]

Comment on attachment 98411 [details] [diff] [review]
v1 patch

r=adamlock

Looks ok, but can you submit a diff -b just to make it a little easier to see
what changed?

Comment 28

[rpotts (gone)]

Comment on attachment 98411 [details] [diff] [review]
v1 patch

sr=[e-mail]

Comment 29

[Darin Fisher]

Attachment: v1 patch w/ whitespace changes removed

Comment 30

[Darin Fisher]

fixed-on-trunk

Comment 31

[Christian :Biesinger (don't email me, ping me on IRC)]

+    PRBool offline;
+    nsCOMPtr<nsIIOService> ios(do_GetIOService());
+    if (ios)
+        ios->GetOffline(&offline);
+    return offline;

um, bad. if ios is NULL for some reason, you're returning whatever is currently
in memory at the position where the offline variable is... you should probably
initialize it when declaring it.

Comment 32

[Darin Fisher]

thx man!  fix checked in.

Comment 33

[José Jeria]

Just tried this out. Started Mozilla and went offline, then I typed in 
http://www.fragzone.se
in the url bar and hit enter.

You see that the page starts loading, you get 3 alerts with "this document
cannot be displayed in offline". Pressing them away and it still loaded the rest
of the page. 
Is this correct behavior?

Comment 34

[José Jeria]

This behavior only happends when you have that url in the cache. Otherwise it
works correct.

Comment 35

[Darin Fisher]

ok, so it looks like some of the iframes or maybe some of the popup ads are
failing to load because we're offline.  the URLs for those are probably
dynamically generated or something, which means that we wouldn't have a local
copy in our cache.  seems like we either need to only show this error dialog for
toplevel loads, or we need to start using error pages by default.

i filed bug 168992 for this problem.

Comment 36

[Dimitrios]

"seems like we either need to only show this error dialog for
toplevel loads, or we need to start using error pages by default"

Second solution seems safer, but bug 157004 and bug 156997 should be addressed
first (amen).

Comment 37

[Adam Lock]

nsWebShell::EndPageLoad sets isTopFrame to true for top-level documents. If
necessary, the error could be supressed when it is false, i.e for subframes and
iframes.

Comment 38

[John Unruh]

Verified fixed.