(Note: this is filed as part of the “Paper Cut” bugs — we assume that there may be multiple existing bugs on this. Please make them block this bug, and we will de-dupe if they are indeed exactly the same. Thanks!) We can detect the network status reliably across all our supported OSes now (if not, let me know), so showing this in the UI is redundant, and confusing. The only valid case left is for developers that want to test their offline app functionality, so we should make sure there's an extension available for this that they can install for this purpose, or make it available as an about:config preference. The one thing that needs to be changed in the current approach is that localhost should NEVER be offline. Right now, Firefox automatically goes into offline mode when the network is missing, but also sets localhost (and its associated IP equivalents) to be offline, which confuses the heck out of you if you try to do development locally when without a network.

> We can detect the network status reliably across all our supported OSes now Do you have details? To my knowledge, that is impossible unless you actually try to ping some Internet hosts. For example, I have a local network, and a DSL router which makes the connection to the ISP - a very common scenario (I'd guess the majority of the average users, at least here in Germany and France). The PC will always have "network" (Ethernet), and can reach other hosts at home, but not the Internet. It's even more complicated at companies, where intranet access is common and frequent. There, whether you are "online" or "offline" when you have intranet access but not Internet access is a matter of viewpoint and situation.

And in case you think "have Ethernet" = "online" is fine: That would be factually untrue, and would render the feature fairly useless. Note that now even web apps depend on it, with HTML5 offline apps etc. - that's where the online/offline feature gets really useful. For web apps, and for users most of the time (but not always), what's interesting in "online" is whether you can reach Internet servers. And whether you have an Ethernet or WiFi connection has very little relation to that, as explained, because many users will almost always have Ethernet, but no Internet access.

I don't mind whether "Work Offline" stays or goes, but either way, the localhost issue needs fixing. Perhaps a separate bug would be best?

Windows Vista and 7 should have indication of internet access vs simple lan access (INetwork::get_IsConnectedToInternet)

> the localhost issue needs fixing. Perhaps a separate bug would be best? That's bug 87717 and bug 339814

Please don't take away the "work offline"!!! It's a very efficient way of browsing our browser cache, even when we're only. Which is handy for some people... I have already nagged Limi on his twitter about this... Sorry about that :blush:

Working offline is, like private browsing, a change in the way users face the web, so turn "File/Work offline" into "Tools/Start Offline Browsing" and make it work just like 'pb': inform the user, sever access to everything but localhost without closing already open tabs and, maybe, present a frienly interface to search/filter/sort and browse the cache. Since users are already familiar with 'pb', namely how to turn it on, recognize when it is on, and turn it off, the only actual difference would be what it does. The rest of the time FF would be always online and free from the hazards of network status detection, while retaining the ability to go offline. Eventually there'll be more and more browsing modes and having a consistent way to using them won't hurt. Just in case, by "modes" I mean ways to "access" the web and not ways to "perceive" it.

We could move work online to the developer sub-menu, but in that case it would only make sense if the majority of Web developers actually use the functionality.

Does the majority of web developers actually use stuff like character encoding? Since it's on auto detect, there is little reason to use it, right? Anyway, the developer sub-menu sounds an ok place to me, but I simply hate that it's called "developer" sub-menu. This isn't the place for this discussion though. But the thing is, if we give the developer sub-menu an appropriate name that isn't counter-intuitive and weird, "work offline" should fit right in.

Alex, unless comment 1 and 2 are entirely solved, and I don't see how they *can*, this needs to be a WONTFIX. And online/offline is important, given that we have part of HTML5 / WHATWG is exactly about offline apps.

>I have a local network ... whether you are "online" or >"offline" when you have intranet access but not Internet >access is a matter of viewpoint and situation. I don't understand why we need a global toggle for the entire browser, can't we fall back to cache on a request per request basis? If I'm on an airplane, and I try to access my web mail, shouldn't that fall back to cache and HTML5 offline access, even if I forgot to tell my browser that I was on an airplane? And if I type in an IP address of my friend's web server (which for some reason outside of the realm of likelihood, is on the local network and *also* on the airplane with me), shouldn't that just work?

OK, so you try to access and it fails with "host unreachable" (we'd need to be specific about the error code here), and we enable "offline" for that host or domain. How would you go "online" again? (You can't keep trying to ping the host all the time in offline mode)

(FWIW, a more realistic scenario is that I'm at home or in the office, and maybe have a bunch of computers/servers there, too, and my Internet connection is broken. Happens for me fairly often, for various reasons.)

>How would you go "online" again? (You can't keep trying to ping the host all >the time in offline mode) Is there anything wrong with checking if the host is reachable when the user tries to reload or navigate to it again? >(FWIW, a more realistic scenario is that I'm at home or in the office, and >maybe have a bunch of computers/servers there, too, and my Internet connection >is broken. Happens for me fairly often, for various reasons.) right, the point that I was trying to get at is that the ritual of placing Firefox into offline mode when boarding a plane so that you can correctly access cache is just offloading the detection of network status to the user. I might be wrong but in online mode (with no connection) does Firefox ever show you what it has cached? (my experience is that it doesn't).

> > How would you go "online" again? > Is there anything wrong with checking if the host is reachable when the user > tries to reload or navigate to it again? Yes, lots of useless and futile requests. More importantly, what do you do with XMLHttpRequest? Most offline apps use that, and are never really "reload"ed, not even manually. > just offloading the detection of [whatever] to the user Yes, we do that whenever the computer can't do it himself, reliably. But your idea to react on "host not found" errors is good. We just need to solve the "go online" case. How about a button or info bar that appears for sites in offline mode, and allows the user to manually switch to online mode again? With the option to tell Firefox "you guessed wrong, stay online". That would have the added advantage that "host not found" can come for many other reasons that no Internet connection, e.g. because the server really dropped off the net, or I have tripped over the power cord, or whatever. You don't want the offline mode in this case. So, an info bar or whatever would be informative and good to tell the user what's going on, what happened and how we reacted on it and what he can do now.

(In reply to comment #15) > But your idea to react on "host not found" errors is good. We just need to > solve the "go online" case. +1 > How about a button or info bar that appears for sites in offline mode, and > allows the user to manually switch to online mode again? With the option to > tell Firefox "you guessed wrong, stay online". I was thinking the same. But if it guessed right, and I'm going to spend several hours using it offline I'm likely to close that bar. So the "go back online" UI still needs to be present elsewhere. To make a stab at answering the "Where then?" question, I'd just say that almost anything beats the "File" menu IMO. Tools / next to Private Browsing sounds good, as suggested by palmiche. > don't want the offline mode in this case. So, an info bar or whatever would be > informative and good to tell the user what's going on, what happened and how > we reacted on it and what he can do now. It would certainly be nice if an info bar popped up and the page remained visible, instead of the current behaviour of replacing the page with "Site unavailable" with no way to bring back the page.

>Yes, lots of useless and futile requests. >More importantly, what do you do with XMLHttpRequest? Most offline apps use >that, and are never really "reload"ed, not even manually. Is there any reason for us to want to limit our number of potentially useless requests? Let's say we always checked at a certain interval (gmail for instance handles this themselves right now). Many of those requests would end up being futile, but at least then the application could seamlessly work, using only information it has access to, and without having to bother the user with any questions.

> I'm going to spend several hours using it offline I'm likely to close > that bar. I personally think it should stay always. The lack of connection is a bigger limitation that the screen space the bar takes. (That is a detail, but it does mean we wouldn't need a menu item.) > Is there any reason for us to want to limit our number of > potentially useless requests? Yes, it can cause problems. Networks are very diverse and have very different characteristics. The "host not found" can take a long while to return. An attempt can even trigger a modem dialout, in fact that's pretty standard for modem users, and even for some DSL users with a time-based tariff or with a configuration to PPP on demand (yes, I've seen that). In that case, you'd constantly trigger PPP dialouts and possibly dialer dialog popups, that will fail anyways. In fact, that "automatic dialog" may be one of the main reasons why "offline" mode existed in the first place. Some users really pay per minute, and want the automatic dialout, but at the same time may want to use the browser to look at local documents, without fear of clicking on the "wrong" external link.

Under a model of each site having online or offline status, modem based users with local networks could still limit their minutes, they would just have to close tabs to non-local resources.

Alex, the problem is that if you try getting the page from the site, you typically trigger a modem dialout.

Please don't remove "Work Offline". * The Save Page As dialog bypasses Adblock Plus. Work Offline keeps Firefox from downloading all those web beacons and ads. * I tinker with Greasemonkey. Never have I gotten a script right on the very first try. I always have to reload the page numerous times. Work Offline keeps Firefox from re-downloading the same content ad nauseum when reloading the page.

See bug 598719 for a possible alternative to the overall functionality of "work offline".

Here is another reason to keep Work Offline menu. It is usefull! I use Work Offline as a privacy feature for when I'm not browsing, but my computer and browser are running. This way I don't get any updates for the social stuff, feeds, appear offline to everyone, etc, but the state of the browser is preserved and I'm one click away from resuming my web interactions.

Dup of bug 539535?

So, I had no idea that we have a preference for this, but we do. Can we at least flip network.manage-offline-status to "False", so Firefox doesn't do this for you without you asking for it? I'm fine with shipping with Work Offline available in a menu, but I don't think we should do it for you. That's what I'm trying to fix with this bug. :)

Alex, would you mind filing a new bug about this, instead of morphing this one? We'll then revert this to the original title "Work offline" should go away" and WONTFIX it.

Yeah, I didn't realize this was as easy as changing one of our existing preferences. I would imagine that we both saw the same article: http://lifehacker.com/5714560/stop-firefox-from-automatically-entering-work-offline-mode the problem with automatically entering work offline mode, is that the user by default will have no idea how to undo the operation (since it was done for them). We try to mitigate this by providing instructions in our UI, but as the article notes, this is a behavior that can get annoying.

(In reply to comment #27) > Alex, would you mind filing a new bug about this, instead of morphing this one? > We'll then revert this to the original title "Work offline" should go away" and > WONTFIX it. Done, bug 620472. I still think Work Offline should go away, so this isn't WONTFIX, but we should do the simplest thing first.

I hope this is what is being asked for and I'm not wasting anyone's time. =)

Comment on attachment 506635 [details] [diff] [review] browser-menubar.inc patch for #611568 and #565564 This patch is obsolete, see Bug #611568 for the patch that takes care of this.

Removes work offline from the browser menu (browser-menubar.inc).

Actually, we're not doing this for 4.0, the way to solve it is to not let Firefox' broken detection code do this automatically for you, as detailed in bug 620472. Sorry if this was still linked from areweprettyyet.com, it shouldn't have been.

Comment on attachment 506650 [details] [diff] [review] Removes Work Offline from the browser menu. Clearing review, Dolske has enough on his plate. :)

Comment on attachment 506650 [details] [diff] [review] Removes Work Offline from the browser menu. Trying again.

Yeah sorry about that Brian, I accidentally forgot to remove this bug from the mockup.

Removing myself since this is looking like a WONTFIX.

Or at the very least pushed back to a future release.

(In reply to Alex Limi (:limi) — Firefox UX Team from comment #0) > The only valid case left is for developers that want to test their offline > app functionality... What a ****! I personally and some other ppls that I know regularly uses "Offline mode" when, err... when offline, damn it. And it's very handy.

We DO NEED offline mode at least for: 1. Use cached pages instead of new/unavailable. 2. Prevent browser from updating cached pages (i.e. deleting "old good data" unavailable online). 3. Prevent browser from sending any HTTP requests to any server (especially AJAX, page refreshers and [Flash] plugin activity). 4. Prevent browser from triggering errors while trying to request unavailable online data. These are depended items (1+2, 3+4) but trying to workaround one of them (e.g. with external cache explorer) doesn't resolve others.

This should be WONTFIX but Offline mode rather moved from File to Tools or Tools > Developer.

This doesn't quite put this footgun in the locked cabinet it deserves, but at least it tucks it behind some books on the top shelf.

Comment on attachment 806999 [details] [diff] [review] Moves "Work Offline" to Tools -> Web Developers. I don't think we should move this. We probably should get rid of it. What was the plan for Australis?

(In reply to Florian Bender from Bug 918226 comment #1) > This is an important developer option for testing offline behaviour of > WebApps (sometimes you don't want to turn off WiFi / unplug the network for > the whole system but just the browser), so please move this to the Dev menu. … and don't remove this option completely. (reposting here because this is actually not Australis-specific)

Mike Hoye, I appreciate that you use the old bug instead of just filing a new one. This keeps the old arguments in sight. Part of the discussion above is about the automatic offline switch going wrong. Luckily, that was disabled in bug 620472. That makes it easier to fix this bug here.

Gavin: Australis has shipped. Are you still of the same thinking about this?

I still don't think we should move it (doesn't buy us much, annoys the few users who do use it). Bug 939318 may have improved the case for removing it entirely (in that it should address one of the common use cases for this function, "reset network state due to network changes"), but it's not the real "online detection" that comment 0 here was referring to.

I still think this is a user-facing footgun, even if it's useful for devs, so I'm happy to clean up my patch and move it to Tools, Tools->Developer or the dustbin of history. I'd favor option #2. A crisp answer would make this a good first bug for a new contributor, also.

Footgun or not, at least with bug 620472 FIXED it's crystal-clear what the "Work Offline" menuitem does: it means "Pretend that the Web has disconnected, and (temporarily) don't access it". Once upon a time, going offline then online was a quick way of resetting the DNS cache, and I don't remember how fully the corresponding problem (that the DNS cache lifespan exceeded the DNS record's TTL, causing timeouts when a domain changed IP addresses in the course of a browser session) has been fixed. There are other valid uses, most of which have been mentioned in previous comments, I'm not going to repeat them; I would sum them up in one sentence which used to be a kind of unofficial Mozilla motto some years ago: More power to the user.