Closed Bug 424626 Opened 16 years ago Closed 16 years ago

(linux) Firefox is put into offline mode on startup when NetworkManager is running but not controlling the active network interface (e.g. when using PPP)

Categories

(Firefox :: Shell Integration, defect)

3.0 Branch
x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: bshanks2, Assigned: wolfiR)

References

Details

(Keywords: fixed1.9.0.1, relnote, Whiteboard: [MU+])

Attachments

(4 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5pre) Gecko/2008032215 Minefield/3.0b5pre
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9b5pre) Gecko/2008032215 Minefield/3.0b5pre

On my Debian system, I had the NetworkManager service running, however, my wired network interface was controlled manually (in my case, the relevant entry in /etc/network/interfaces was "iface eth1 inet static", which prevents NetworkManager from managing that interface). Therefore, when using the wired interface, I had network access, however, NetworkManager reports no network devices present (the commandline program nm-tool yielded:

"
NetworkManager Tool

State: disconnected

print_devices(): didn't get a reply from NetworkManager.
There are no available network devices.
").

This caused Firefox 3 to startup in Offline mode, which forced me to manually uncheck File->Work Offline at the beginning of each session.

As a workaround, I now disable the NetworkManager service before starting Firefox (now nm-tool reports
"
NetworkManager Tool

get_nm_state(): didn't get a reply from NetworkManager.


NetworkManager appears not to be running (could not get its state).
").

If NetworkManager intends that it is accurately reporting the "online" status of the computer (does it? or does it intend to only report the state of the connections that it is managing?), then I suppose that NetworkManager has a bug.

However, in any case, Firefox should have a config option that the user can use to tell Firefox not to query NetworkManager upon startup. 


Reproducible: Always

Steps to Reproduce:
1. Install NetworkManager
2. Configure things so that NetworkManager does not control any of the active network interfaces (I believe you can do this by adding all of the active interfaces to /etc/network/interfaces, providing each of them with at least one option other than "auto" or "dhcp"). nm-tool should report state "disconnected", as described above.
3. Start Firefox. Observe that File->Work Offline is checked.
Actual Results:  
File->Work Offline is checked

Expected Results:  
I would expect that if I start Firefox when I am online (able to access remote web pages), and File->Work Offline was not checked at the end of my previous session, that File->Work Offline would not be checked upon startup

I have heard of other people having similar problems in slightly different circumstances (see https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/191889).

Since NetworkManager cannot currently be relied upon to accurately give the online status of the system, I am requesting an option that tells tell Firefox not to query NetworkManager upon startup. I could not find such an option at http://kb.mozillazine.org/Category:Preferences.
confirmed
I would propose to add a (hidden) pref to disable NM status use.
(The openSUSE Firefox 2.x has that feature but the FF3 code is different so we need a new patch)
Severity: minor → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x?
This sounds like a dupe of a bug I filed where I noticed in a Linux VM I was starting up in Offline mode, Bug 419736.
It's most probably a bug. Feel free to dupe that one but the summary of the other one is not really helpful ;-)

It's known that if NetworkManager is running but is not actually handling every online connection it tells Firefox that it is offline.
(In reply to comment #3)
> It's most probably a bug.
                       ^^^ dupe that is.

Each distro handles ignored devices differently.  Even though NM would know the MAC address of the device that it is told to ignore, there's no way NM could know whether or not that device is up and active, precisely because you've told NetworkManager to ignore that device.

NM 0.7 will help this because it will work for a lot more users (static IP, network before login, etc).

However, if you are making NetworkManager ignore certain devices, then you cannot expect NetworkManager to know anything about those devices, much less whether that device is active and has an IP address and is therefore online.  I'd suggest turning off NetworkManager in that case, and then FF should just thing you're online.
Yeah, what Dan said.  If you're going to tweak the default settings to be outside of the use case, there's going to be more than simply Firefox which is going to be affected.  Other system services are moving to use NM to determine on/off state, and you're expected to disable NM if you aren't going to use it for every device.

I'd recommend a release note reminding people that they should disable the NetworkManager service if they are managing network connections by hand.
Basically I agree and with NM 0.7 that's probably almost no issue anymore.
But earlier versions of NM weren't able to manage 3G and all other dialup things.
So people had NM running for their WiFi/cable devices but used other tools to connect with their 3G devices for example. That was a major use case the last two years.
So inventing a hidden pref wouldn't harm and wouldn't be too hard as well.
(I'm not talking about ignoring special devices but just disabling NM status support for special cases)
I'm seeing probably a person a day find their way to IRC and complain that their firefox starts in offline. Myself I could not figure out how to make ubuntu use the networkmanager which it installs by default work so I had to uninstall it. This is somewhat unintuitive and I think we should do something about this for Firefox 3.
Flags: blocking-firefox3?
I get people all the time asking "Why doesn't NetworkManager see my network device?".  Every single time it's because that person is using Ubuntu and they have configured that device in "Manual" mode, which is an Ubuntu specific hack and causes me no end of trouble upstream.

I can't help what stupid choices distributions make.  The NetworkManager in Fedora, SUSE, and other distros just works when used with FF3.  If this is worked around, you understand you're working around _Ubuntu_, not NetworkManager.
I couldn't get ubuntu to connect in the networkmanager mode (whatever it is), and I have also heard complaints from Fedora users.

Sure we might be doing something to work around a problem in a distribution. If that distribution represents a large enough portion of the user base I think that is a reasonable things to do, and I know Mozilla have done similar things in the past (disabling IPv6 where certain platforms were broken). I do not know what the figures are, I can only say I am seeing this issue crop up frequently.
Part of that is because Ubuntu ships many quite horrible-quality drivers that simply don't work with wpa_supplicant and NM, because they don't support WEXT properly.  I laud their efforts to make as much hardware work as possible, but unfortunately the _quality_ of that support for many drivers just sucks.

If you're using out-of-kernel drivers (ubuntu has in the past had 4 different _stacks_ in their kernel, including net80211, linux-wlan-ng, vendor drivers, etc not to mention shipping ndiswrapper) then there's not much that _anyone_ can do to guarantee the quality of those drivers, and every time somebody asks why their card doesn't work when it uses an out-of-kernel driver, I can usually find 3 or 4 major errors in the driver's WEXT conformance.

Yes, Ubuntu has a large user base and it's probably something FF has to work around given that.  But many of the reasons that NM doesn't work for people using Ubuntu are specifically because of bad choices Ubuntu has made when packaging NetworkManager (often for ndiswrapper and madwifi) and when stuffing bad quality drivers into their kernel packages.

Doesn't help the users of FF though since you obviously can't blame them for the distro they use.
I run into this problem on Fedora, when I'm in a hotel with no ethernet and no wireless, and use kppp to connect to the internet using a mobile phone. Maybe I should be using some other software for doing the PPP connection, that network manager is aware of? However, that would require that I migrate all the configuration information for various access points into another software.

Am I expected to stop the NetworkManager service when I use kppp?
As I'm understanding things, this issue won't hit even a majority of Ubuntu or Fedora users, as they have to be doing pretty special things to their network configurations. Is there a workaround that we can relnote?
Flags: blocking-firefox3? → blocking-firefox3-
(In reply to comment #15)
> As I'm understanding things, this issue won't hit even a majority of Ubuntu or
> Fedora users, as they have to be doing pretty special things to their network
> configurations. Is there a workaround that we can relnote?

The only workaround I could find was to uninstall the NetworkManager.
I had already uninstalled network manager prior to noticing this bug because it didn't manage my wireless dongle well, and am using RutilT wlan manager but still get this bug so it's not restricted to NM.
I am experiencing the same problem using wvdial to connect with my 3g usb device. NM states that there is no connection.
I am using Firefox 3.0b5.
Please fix this. NetworkManager 0.6 is not able to monitor the state of PPP interfaces and NetworkManager 0.7 has not been released yet.

As a result, Firefox is broken out of the box for everyone that uses PPP (both a standard dialup modem and an ADSL modem directly connected to the computer) and also has NetworkManager installed - which they are likely to have a) because it's installed by default by many distros or because they use it to manage their Ethernet connections. And worse, to fix it you need to unset the "File->work offline" checkbox *every time it starts up*. This is a terrible user experience. If offline detection isn't perfect, there should be a way to enable it.

Setting priority to major and attempting to renominate as blocker since it breaks Firefox for all dialup users and is very irritating to work around.
Severity: normal → major
Flags: blocking-firefox3- → blocking-firefox3?
Version: unspecified → 3.0 Branch
> If offline detection isn't perfect, there should be a way to enable it.

(and of course I meant a way to disable it)
Dan William's suggestion that the users should disable NetworkManager is not valid.

In my case I use NetworkManager to manage ethernet and wireless. But I also have a UMTS modem and no way for NetworkManager to deal with it AFAIK. I use NM for ethernet and wireless, and also use nm-applet to start the UMTS connection.

I believe this is a valid use case, particularly in my country where UMTS modems are usual.

So, yes this bug is annoying and the workaround (disabling NM) is not valid for me.

Thanks.
We're not going to block on this, sorry.  Its an edge case, and caillon's comments still seem to make the most sense.  Its not that it isn't a valid use case, but we're doing what all NM-enabled apps are doing.  You can manually force online if needed, but it seems like this is a NM issue to address in time.
Flags: blocking-firefox3? → blocking-firefox3-
I disagree that "everyone with a dial-up modem or PPPoE or PPPoA connection that also uses an app (networkmanager) that's installed on most distros by default" is an edge case. Updating summary accordingly.

For these users, is not a question of them tweaking the NM config, it's something that's broken out of the box. And since NM 0.7 has not been released, it's not fair to tell them to use it.

If someone volunteered to write a patch to have a hidden pref do this, would it be considered for inclusion?
Summary: (linux) offline mode ("work offline") inappropriately enabled upon startup when NetworkManager is running but not controlling the active network interface → (linux) Firefox can't connect on startup when user is using PPP and has networkmanager installed
Mike, Firefox is the only app in Ubuntu I've found with this behaviour. Could you give me an example of another one?
Flags: blocking-firefox3- → blocking-firefox3?
Just in case someone is missing the point: do you have any idea how painful it is to go thru 30 tabs having to refresh each one of them just because Fx3 tried to be smart and started in offline mode?

Thanks.
Summary: (linux) Firefox can't connect on startup when user is using PPP and has networkmanager installed → (linux) Firefox is put into offline mode on startup when user is using PPP and has networkmanager installed
(In reply to comment #23)
> If someone volunteered to write a patch to have a hidden pref do this, would it
> be considered for inclusion?

It would definitely be considered. I don't know that code, so it's hard for me to intuit if that's something that's easily preffable or not in ways that aren't potentially harmful to the rest of the product.

While I (and mconnor, trust me) do understand the pain that this causes a subset of the Linux using audience, I want to stress that Firefox is doing what the operating system tells us: in this case, the operating system reports that there is no network connection, and we obey. It is indeed unfortunate that the operating system is misinforming us, and I'd be happy to do what I can as interim fixes as long as it's not in ways that remove a useful feature (automatic online/offline detection) for the vast majority of our users.

This will not block the final ship of Firefox 3.
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.1?
Flags: blocking-firefox3?
Flags: blocking-firefox3-
dcamp: should this be here, or Core::Networking?
A minimal patch to add a hidden pref for users (or, one hopes, their distros) to use to disable NM events would be welcome.  Even if it didn't make it into 3.0, it sounds like we'd want it in 3.0.1, and Ubuntu might take it on their side more eagerly given that it seems to be pretty much limited to the lies that Network Manager tells us on their setup.

Joao: right click a tab, "Reload All Tabs". :)
Marking wanted-firefox3+ based on discussion with Beltzner; any such patch would need to be very prompt, though.
Flags: wanted-firefox3+
(In reply to comment #26)
> While I (and mconnor, trust me) do understand the pain that this causes a
> subset of the Linux using audience, I want to stress that Firefox is doing what
> the operating system tells us: in this case, the operating system reports that
> there is no network connection, and we obey. It is indeed unfortunate that the
> operating system is misinforming us, and I'd be happy to do what I can as
> interim fixes as long as it's not in ways that remove a useful feature
> (automatic online/offline detection) for the vast majority of our users.

Just to point out, it's not the operating system reporting that, it's NetworkManager...
Attached patch patchSplinter Review
Tentative patch as base for discussion.
This first try keeps everything in place (dbus connection, NM listener) but just does not update the network status.
I wasn't sure about the pref name. There might be better suggestions.
And I wonder what to do if the pref-service is not available for some reason (probably at startup).
This patch looks good to me. The pref-service should be available here.

I'm not sure about the pref name.

Seems to me that NetworkManager itself should have a setting "some devices not currently managed" (either manually configured or automatically detected), and if that is true then it shouldn't send StateChange signals since it doesn't know what the true current state is.
(In reply to comment #30)
> Just to point out, it's not the operating system reporting that, it's
> NetworkManager...

Excuse me while I go postal here, but this kind of nonsense is why people hate developing apps for Linux.
(In reply to comment #10)
> I get people all the time asking "Why doesn't NetworkManager see my network
> device?".  Every single time it's because that person is using Ubuntu and they
> have configured that device in "Manual" mode, which is an Ubuntu specific hack
> and causes me no end of trouble upstream.

This is not really true. Manual mode devices blacklisted for network manager will make NM always expose the "online" state.

The problem here is not our ifupdown blacklisting, but ppp, which isnt really supported by network manager 0.6.6.

(In reply to comment #12)
> Part of that is because Ubuntu ships many quite horrible-quality drivers that
> simply don't work with wpa_supplicant and NM, because they don't support WEXT
> properly.  I laud their efforts to make as much hardware work as possible, but
> unfortunately the _quality_ of that support for many drivers just sucks.
> 
> If you're using out-of-kernel drivers (ubuntu has in the past had 4 different
> _stacks_ in their kernel, including net80211, linux-wlan-ng, vendor drivers,
> etc not to mention shipping ndiswrapper) then there's not much that _anyone_
> can do to guarantee the quality of those drivers, and every time somebody asks
> why their card doesn't work when it uses an out-of-kernel driver, I can usually
> find 3 or 4 major errors in the driver's WEXT conformance.
>

I agree that there is a bunch of crappy drivers out there.

However, most drivers you referred to in your blog appear to be drivers for old hardware that dont have a modern replacement. Should we just drop support for them completely in order to stop network manager from misbehaving?

 
> Yes, Ubuntu has a large user base and it's probably something FF has to work
> around given that.  But many of the reasons that NM doesn't work for people
> using Ubuntu are specifically because of bad choices Ubuntu has made when
> packaging NetworkManager (often for ndiswrapper and madwifi) and when stuffing
> bad quality drivers into their kernel packages.
> 
> Doesn't help the users of FF though since you obviously can't blame them for
> the distro they use.

IMO, the network manager online state is not reliable by design and probably its main use case is to provide a way to fast-fail attempts to connect to a network resource.

Thus, I think that network-manager could tune its heuristic to always expose "online" when there is a route to any network.

What do you think?

We have to interpret NM_STATE_DISCONNECTED as "you definitely can't connect to the internet" and NM_STATE_CONNECTED as "maybe you can" ... since you could have a link to a router that's not connected to anything else. I hope NetworkManager agrees.
(In reply to comment #31)
> Created an attachment (id=322620) [details]
> patch
> 
> Tentative patch as base for discussion.
> This first try keeps everything in place (dbus connection, NM listener) but
> just does not update the network status.
> I wasn't sure about the pref name. There might be better suggestions.
> And I wonder what to do if the pref-service is not available for some reason
> (probably at startup).
> 

I am fine to pull this in as a quick fix. Just curious, why a hidden pref?

(In reply to comment #37)
> I am fine to pull this in as a quick fix. Just curious, why a hidden pref?

It doesn't need to be that hidden IMHO. Adding a default value of false to the prefs should be fine. It should be "hidden" in the sense of not having any UI though. If noone cares for the pref name I'll keep it and add the default pref in the next patch.
If NetworkManager is not able to control your default your (and the 0.6 that Ubuntu includes isn't capable of doing so for things like mobile broadband or PPPoE, which 0.7 fixes) then you should turn NetworkManager off and use your normal distro network config scripts.

NetworkManager is appropriate for cases where it is able to control the default route.  If it is not, then you should turn it off for that machine.

If Firefox doesn't assume that when the NM dbus service is not around, that the machine is online, then FF needs to be fixed to assume so.  But when the NM service is around, then it is assumed that NM is managing the default route, and thus can be asked for authoritative network status.  If you have made your primary network device "managed" rather than roaming mode (an Ubuntu-specific patch to NetworkManager) then you aren't using a configuration supported or cared about by upstream NetworkManager developers.  In that case, turn off NetworkManager.
Dan, interesting point-of-view, but it fails in real life.

My two main internet connections are a UMTS modem and wifi. NM is great for wifi, and it seems absurd to me that I should change my present "pick the wifi network from NM list" to 1) start NetworkManager, 2) start nm-applet and 3) "pick the wifi network from NM list" everytime I change from UMTS to wifi.

As 0.7 is not out, the mistake is on Firefox by assuming that NM is able to manage all network connections. The fact that it can manage somethings well and others not at all, doesn't mean it's not useful and shouldn't be on. It's just Firefox's assumption that is wrong.

Thanks for a great program.
João: yes, that sucks.  But in your case, NM 0.6 is simply not capable of correctly managing the UMTS card.  It's just not built for that.  I maintain that FF is correct in assuming that when NM is running, NM reports accurate status.  If NM is not able to correctly control the default route of your primary device, then you should not be running NM.  It doesn't matter if NM can easily control the wifi, because that's only a _part_ of the total connectivity of your laptop.  Until your distro updates to 0.7, there are other tools that will probably work better for you because they are limited to just controlling the wifi (wifiradar, etc).
Sorry for spamming this bug, but Dan, I disagree. The facts are:

- Firefox 3 uses NetworkManager to determine whether it's online
- The current version of NetworkManager (0.6) does not support PPP connections
- Some of Firefox's users use PPP
- NetworkManager is installed by default on many distros

Given the above, if we look at it from Firefox's perspective, NetworkManager is not a 100% reliable way of finding out if there is an Internet connection, because there is a class of users for which it fails. These users won't know what the problem is and won't know that they need to disable NetworkManager. And the distros can't disable it for them because they don't know if the users need it for other connections like Ethernet or wifi. So adding a pref to Firefox to allow it not to trust NetworkManager is a reasonable idea.

The pref can default to off (i.e., use NetworkManager), and distros who ship the current version can turn it on in all.js. When NetworkManager 0.7 is released, they can disable it again. Everybody wins.

If NM 0.7 was out now, I'd definitely agree with you. But I think saying that this Firefox feature should only work on an unreleased version of NM is not a reasonable position.

When do you expect NM 0.7 will be released?
Some distros probably turned on NM 0.6 by default before it was ready for the majority of that distros userbase.  We didn't turn NM on by default in Fedora until Fedora 9 mainly because we felt that only NM 0.7 covered enough use-cases to be turned on by default (PPP for example).

I can't help what distros that I don't have control over do with NM, that's Open Source at its best (or worst).  The distro's users have to deal with the consequences of that distros decisions.

I don't personally have a problem with FF having this preference.  I'm simply correcting mistaken viewpoints and impressions that people and distros have about NM.
(In reply to comment #42)
> If NM 0.7 was out now, I'd definitely agree with you. But I think saying that
> this Firefox feature should only work on an unreleased version of NM is not a
> reasonable position.

Hm, if you don't use "unreleased" software, how do you even know about this bug?  I don't remember the Firefox 3 release announcement yet.  ;-)

Maybe the real thing we should fix is to just bump the NM requirement in configure to require an 0.7 build for this support to be built.
(In reply to comment #44)
> Maybe the real thing we should fix is to just bump the NM requirement in
> configure to require an 0.7 build for this support to be built.

That sounds pretty tempting.  RC2, and therefore in all likelihood FF3, closes in 48 minutes.  Let's get this done if we're going to do it.  (Reviews, testing, tests in suite, approval request with risk profile.)
> Hm, if you don't use "unreleased" software, how do you even know about this
> bug?  I don't remember the Firefox 3 release announcement yet.  ;-)

That's different! We're developers ;-)
(In reply to comment #44)
> Maybe the real thing we should fix is to just bump the NM requirement in
> configure to require an 0.7 build for this support to be built.

I still would vote for the simple "ignore" patch.
- NetworkManager isn't a compile dependency at all currently
- I still have to see that NM 0.7 works in real life for every connection type
(In reply to comment #44)
> Maybe the real thing we should fix is to just bump the NM requirement in
> configure to require an 0.7 build for this support to be built.

Sounds like a fine plan to me. I'll start looking, but there's no guarantee I can figure out how to do this in 32 minutes, I don't even have a local copy of the tree...     
If you think that we should take that patch, you should ask for review on it.
Comment on attachment 322620 [details] [diff] [review]
patch

Asking someone for review. (That's what I love about the mozilla project. The roulette about finding the correct reviewer (within a few minutes) if one doesn't do it daily) IIRC, sr is not needed for toolkit?
Attachment #322620 - Flags: review?(mconnor)
Attachment #322620 - Flags: approval1.9?
If libnm_glib >= 0.7 (and therefore, networkmanager 0.7) is not present, don't enable DBUS support.
Comment on attachment 322828 [details] [diff] [review]
Disable DBUS support if libnm_glib 0.7 is not present

Who can review this? Pinging Chris since it was his idea, but perhaps someone else is qualified too?
Attachment #322828 - Flags: review?(caillon)
Attachment #322828 - Flags: approval1.9?
(In reply to comment #51)
> Created an attachment (id=322828) [details]
> Disable DBUS support if libnm_glib 0.7 is not present
> 
> If libnm_glib >= 0.7 (and therefore, networkmanager 0.7) is not present, don't
> enable DBUS support.

Do we know if the mozilla.org build machines have NetworkManager 0.7? If not, they'll need it before this patch can land.
This patch silently disables DBUS if networkmanager 0.7 is not present, so that shouldn't be an issue. I think there's a bug in the patch though, checking now.
(In reply to comment #54)
> This patch silently disables DBUS if networkmanager 0.7 is not present, so that
> shouldn't be an issue.

Sure it is an issue, as it would disable DBUS support for me, as I use mozilla.org builds.
Comment on attachment 322828 [details] [diff] [review]
Disable DBUS support if libnm_glib 0.7 is not present

You could simply combine the two things into one PKG_CHECK_MODULES call.  E.g. PKG_CHECK_MODULES(MOZ_DBUS_GLIB, dbus-glib-1 >= $DBUS_VERSION NetworkManager >= $NM_VERSION)
Attachment #322828 - Flags: review?(caillon)
Attachment #322828 - Flags: review-
Attachment #322828 - Flags: approval1.9?
Comment on attachment 322828 [details] [diff] [review]
Disable DBUS support if libnm_glib 0.7 is not present

also, since we don't use the glib interface, we probably really do want to use NetworkManager.pc, not libnm-glib.pc
I don't have NetworkManager.pc. Was this added in NM 0.7?
No... that's been around since the start of the project.  It should be in the main -devel package.
Not taking this now, will relnote the interaction with PPP and look at a patch for 3.0.1 when the domain experts (roc, campd) are around.
Flags: blocking1.9.0.1? → blocking1.9.0.1+
Keywords: relnote
Take two: check for NetworkManager.pc instead of libnm_glib.pc, properly define MOZ_DBUS_ENABLED, properly print results, and run the check in only one statement.
Attachment #322828 - Attachment is obsolete: true
Attachment #322833 - Flags: review?(caillon)
(In reply to comment #39)
> If Firefox doesn't assume that when the NM dbus service is not around, that the
> machine is online, then FF needs to be fixed to assume so.

When NM is not around, FF assumes you're online. (Of course! Otherwise we'd be total dunces.)
Comment on attachment 322620 [details] [diff] [review]
patch

I'm not sure why you didn't just ask me for review.
Attachment #322620 - Flags: review?(mconnor) → review+
I still think the best solution is what I alluded to in comment #32. NetworkManager can detect whether it's managing the interface for the default route. When it isn't, it should not send StateChange signals.
Agreed. My patch is just a quick workaround to make Firefox usable on systems where NM might be misconfigured/misplaced or whatever.
I also think that NetworkManager should know when its managing the default route or not but that's not to be discussed here probably.
I also _guess_ that there might be rare situations where even NM 0.7 doesn't manage the network connection even if it's running. So personally I think the configure check isn't a good idea anyway and it's a compile time switch whereas that has nothing to do with the version which is actually running at runtime.
The summary doesn't really reflect the current solution, and I think that while a preference would help as a workaround, it isn't really a solution (the solution is that we should make sure we're getting the right signals for the OS).

So I spun out bug 437453 for adding a preference for turning on/off automatic online/offline. Let's keep working on Linux/NM specific solutions here, and the workaround there.
I have an additional fringe case on this one where I'm running a local web server for field order entry on a few hundred laptop computers.  I NEED network manager because it is easy for my users to understand.  But I have the problem that they are not always online and connect to localhost to place their orders.  Firefox is always starting out in offline mode and I would like to be able to force it to ignore network manager so that they can still use the system.  When they update Firefox to 3.0 I'm going to have a lot of confused people and phone calls to deal with.
Wolfgang's patch should help with that.

Wolfgang, can you land this in mozilla-central or do you want me to do it?
(In reply to comment #68)
> Wolfgang's patch should help with that.
> 
> Wolfgang, can you land this in mozilla-central or do you want me to do it?

I'd like (to try) to land it ;-) (using HG the first time)


Comment on attachment 322620 [details] [diff] [review]
patch

Landed in mozilla-central
(In reply to comment #61)
> Created an attachment (id=322833) [details]
> Disable DBUS support if NetworkManager 0.7 is not present
> 
> Take two: check for NetworkManager.pc instead of libnm_glib.pc, properly define
> MOZ_DBUS_ENABLED, properly print results, and run the check in only one
> statement.
> 

I dont think that this should be determined at compile time. If you want to turn of network manager support based on what NM version is running it should be figured at _runtime_.

Dan, is there a way to request version information of NM through DBus?

Personally, I think that we should take Wolfgang's patch for now.
I agree. The compile-time hack is just a hack so that at least distributors can turn it off. Wolfgang's approach is better.
Summary: (linux) Firefox is put into offline mode on startup when user is using PPP and has networkmanager installed → (linux) Firefox is put into offline mode on startup when NetworkManager is running but not controlling the active network interface (e.g. when using PPP)
Attachment #322620 - Flags: approval1.9? → approval1.9.0.1?
(In reply to comment #70)
> (From update of attachment 322620 [details] [diff] [review])
> Landed in mozilla-central

And? Do we know that the bug fixes the problem and isn't causing any other regressions?

We'll take a well tested patch here, but I'm not sure we'll say that it totally blocks the first branch release. Very much wanted, though.
Whiteboard: [MU+]
Bug 436815 – offline mode turn on/off -- includes reports that seem related to this.I have had to disable NetworkManager to make Firefox 3 usable on my linux PC (running Fedora 9).

The problem is NOT restricted to Ubuntu as suggested in Comment #10

It seems that (1) NetworkManager is at fault in giving wrong information, (2) The Fedora people are at fault in turning on NM by default in Fedora 9, and (3) the Firefox people are at fault in making FF trust NM without allowing mechanisms to override that trust.

The combined consequence of those three faults is that I have wasted several hours in the last few days fighting this problem, until I discovered I could fix it by turning off NM, which I don't need on a PC connected by cable to the router using static addresses. From several other bug reports I think many other people are suffering.

I completely agree with this in comment #25 "Just in case someone is missing the point: do you have any idea how painful it is to go thru 30 tabs having to refresh each one of them just because Fx3 tried to be smart and started in offline mode?" I keep much of my work in multiple tabs in FF.

This terrible behaviour, including being required to refresh each tab manually, forced me back to using FF2 for a while, until I discovered that I could restart FF3 in online mode if I (a) start FF2, then (b) kill it then (c) start FF3 !! (I have no idea why this works, but it may be a clue for a fix.)

Painful, but not nearly as painful as having to restart all my tabs manually.

I've removed the need for this procedure by disabling NM, but, as indicated above, some people need NM (e.g. on laptops used with different connections in different places). So FF3 should either not trust NM, or should provide a way to users to override that trust.

It would not be so bad if the 'work offline' button had an option: 'go online and restart all tabs and windows'. (also suggested in Comment #28, I see.)

Good software designers provide ways of helping users mitigate the effects of faults in other software instead of simply blaming the other software.

Thanks.
(In reply to comment #75)
> (In reply to comment #70)
> > (From update of attachment 322620 [details] [diff] [review] [details])
> > Landed in mozilla-central
> 
> And? Do we know that the bug fixes the problem and isn't causing any other
> regressions?
> 
> We'll take a well tested patch here, but I'm not sure we'll say that it totally
> blocks the first branch release. Very much wanted, though.

Can I get an answer here? Can someone on Linux/3.1apre builds confirm that this helps not hinders?
I am having the same problem on fedora core 9 with an docking bay ethernet that sometimes does not come up when the machine boots.
Comment on attachment 322620 [details] [diff] [review]
patch

a=beltzner
Attachment #322620 - Flags: approval1.9.0.1? → approval1.9.0.1+
MU+ but not blocking1.9.0.1 anymore - if the patch lands (when the tree clears (on the log on the bottom of the sea)) in time that's fine, if not, it'll wait to 1.9.0.2.
Flags: blocking1.9.0.1+ → blocking1.9.0.1-
Mike, just to say that it does fix the wrong behavior for me (Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1pre) Gecko/2008063004 GranParadiso/3.0.1pre). Opening Firefox 3.0 in the same system (with another profile) exhibits the same behavior described in this bug.

Thanks to all,
João Miguel Neves
Checking in toolkit/system/dbus/nsNetworkManagerListener.cpp;
/cvsroot/mozilla/toolkit/system/dbus/nsNetworkManagerListener.cpp,v  <--  nsNetworkManagerListener.cpp
new revision: 1.3; previous revision: 1.2
done

Still needs to be made non-hidden.
Assignee: nobody → mozilla
Keywords: checkin-needed
Attached patch unhide prefSplinter Review
I think that's all what's needed to "unhide" the pref
Checking in all.js;
/cvsroot/mozilla/modules/libpref/src/init/all.js,v  <--  all.js
new revision: 3.759; previous revision: 3.758
done
Keywords: checkin-needed
is this going to land on trunk too?
It already landed on trunk. It's not closed because it's not supposed to be the final solution as I understood.
I also stumbled across this really annoying bug. I use network manager for WiFi at times, but I do not - at my full intention - use it for eth0 yet. I use Debian with guessnet to set a static IP if it detects my home routers IP and MAC address. Granted I could install a DHCP server on my ASUS WL-500g Premium with Debian Etch - and I think I will...

... but actually I really dislike being patronized by computer software. I like to use Network Manager for Wifi, I like to use other setup software for eth0 at my *own discretion*, and I like to use Firefox (at times).

If Network Manager could not control all interfaces it should be honest about offline and online status:

1) If there is a way to still determine reliably whether the machine is off- or online it should be implemented.

2) If not, Network Manager should be honest about it and stop pretending that it nows better than me. It should simply say: Well there are interfaces that I do not control, I have no frigging clue about online state. Go figure. Then thats up to my own decision whether I want to live with that limitation or install a DHCP server on my ASUS router.

I really do not agree with Network Manager insisting on an "all or nothing" scenario. IMHO there are valid reasons for *not* managing all interfaces with Network Manager and NM should support such scenarios as good as it can.

Until either such a solution is implemented in Network Manager, Firefox should give me a way of not using it instead of insisting "I know better than you, the user".
Sorry, sounded a bit harsh I guess. I understand that a patch to disable NM online detection is on the way.
Comment on attachment 327557 [details] [diff] [review]
unhide pref

Does this need landing on mozilla-central as well?
Comment on attachment 327557 [details] [diff] [review]
unhide pref

That's already in mozilla-central. As written somewhere above this bug is still open because of comment #66
The fix sounds awful... isn't there a way to some detection at runtime ? Because if you happen to build with NM 0.7 and somehow users are using 0.6 (which can happen on distros), you're back to where you started...
I guess that's why that fix never was considered really. The currently implemented one for 3.0.1 (cvs trunk) and 3.1 (hg) is the static preference which is at least a band-aid.
Someone marked my other bug, 441491 (https://bugzilla.mozilla.org/show_bug.cgi?id=441491) as a duplicate of this bug, and now that they're filed together it needs to be included in this discussion.

When using the profile manager, you can pick 'Work offline' or leave it unchecked, which is a user input decision. Despite that choice firefox will still consult network manager and change your decision even if you didn't want it to.

Effectively, if you are using network manager properly and are online, starting firefox and choosing 'work offline' will still land you online and loading the pages over the network, even though you actively tried to tell firefox not to do this.
I agree...
I'm having the same bug.
on 3.0.1 the bug is present. ff still starts in offline mode.

I use umtsmon to establish a ppp connection over umts, networkmanager is not involved. Distro is suse 10.3
ff 3.0.1, patch works incorrectly. With VPN-connection firefox always starts offline.

debian lenny
The patch is working correctly. To fix this problem, you need to go to about:config and set the pref "toolkit.networkmanager.disable" to true.
Really works, thanks.

Ебанулись на отличненько :)
Is this patch included in Firefox 3.0.1? I updated to iceweasel 3.0.1-1 in Debian. And I have toolkit.networkmanager.disable set to true. Network Manager from network-manager 0.6.6-2 Debian Package is running.

Still Iceweasel insists on offline mode after startup.

Previously I used the following hacks I have been recommended to try on debian-user-german mailinglist:

prefs.js:user_pref("browser.offline", false);
prefs.js:user_pref("offline.statup_state", "4");

Especially the later one appeared to work with iceweasel 3.0~rc2-2, but it didn't work anymore with 3.0.1 and I removed those two entries.

I will file Debian bug report, too. I think this gotta be fixed *before* Debian Lenny release. Current behavior IMHO is absolutely ridicolous.


I found related upstream bug report for Network Manager:

http://bugzilla.gnome.org/show_bug.cgi?id=418745

I also filed Debian bug reports that Iceweasel does not seem to respect toolkit.networkmanager.disable set to true in my case:

http://bugs.debian.org/491822

And about the behavior of Network Manager which IMHO is not helpful for users wanting to configure the network their way and using Network Manager for just some interfaces. Or scenarios where Network Manager simply does not support all connections:

http://bugs.debian.org/491826

I hope a good solution can be found that offers simplicity, but also does not force all-or-nothing concepts on users with a strong desire of choosing themselves which software they let manage a certain interface.
As I mentioned way back in comment #32, the correct solution is to fix NetworkManager so its StateChange signals are reliable. If there is no way to make its StateChange signals reliable, then it shouldn't send any.

I actually think we should disable this feature by default until NetworkManager is fixed.
I fully agree, Robert, but then thats something for upstream of Network Manager to handle. Apart from the part to at least be able to disable Network Manager support in Iceweasel for now. I have not been able to with Debian's Firefox variant Iceweasel. See: http://bugs.debian.org/491822

Upstream has its own bug report about this issue:

http://bugzilla.gnome.org/show_bug.cgi?id=418745

See my comment there

http://bugzilla.gnome.org/show_bug.cgi?id=418745#c13
(In reply to comment #104)
> As I mentioned way back in comment #32, the correct solution is to fix
> NetworkManager so its StateChange signals are reliable. If there is no way to
> make its StateChange signals reliable, then it shouldn't send any.

The best solution is NOT to rely on any particular tool for managing network connections, but to specify a protocol that can be used by ANY tool that is properly designed.

Hard-wiring a link to something as specific as Network manager, in a tool that is as widely used as Firefox seems to me to be quite misguided.
Compare email: I can use all sorts of email tools to communicate with all sorts of different email servers, because there are well defined protocols.
It would be totally wrong for any widely used tool to assume that everyone uses Thunderbird for reading and sending email, for example.

The great benefit of the unix/linux philosophy is that if protocols are properly designed, users and developers of particular packages can have a lot of freedom in choice of particular tools, interfaces, etc.

E.g.I have not found NetworkManager at all useful, though in some contexts I do find wlassistant useful for connecting with wireless services that don't use wpa. For wpa I prefer to use my shell scripts to launch wpa_supplicant. For static wired connections at home I use yet another mechanism.

As far as I can tell from documentation for NM on the internet, not even the developers (RedHat) expect it to be universally used on linux: it will not meet everyone's needs. So Firefox should not attempt to force people to use it.

If firefox is going to try to take action depending on what network channels happen to be working then it should interrogate the network interfaces, not a tool that only some people use.

> I actually think we should disable this feature by default until NetworkManager
> is fixed.

It should be permanently disabled since there will never be a guarantee that everyone uses NM.

I doubt that NetworkManager will *ever* have the universal role that would justify Firefox relying on it. So, at most this dependency on NM should be an option that can be turned on by people who like to use it. It should not be on by default. 

I am not a networking expert just a user: I use linux all the time, in a variety of contexts and have mechanisms that work fine, without ever requiring NM. Firefox should not force me to start using NM if it does not do what I want. If I accidentally turn NM on Firefox should ignore it unless I specifically request it to use NM.

(In reply to comment #106)
> Firefox should not force me to start using NM if it does not do what I
> want.

We're not forcing anyone to start using NM. If NM is not running, Firefox behaves exactly as if this feature was disabled.

If someone produces a protocol for communicating network status that's more widely deployed than NM, and doesn't require polling, and doesn't rely on unstable or Linux-only kernel interfaces, we'll use it. Let me know when that happens.
First time user of bugzilla today, apologizing for any resulting
rough edges.

424626 is described in the Release Notes for 3.0.1 as having been
fixed, but, it has not been fixed as far as I can observe on my system
(details below).

As best I can tell the present "fixed 1.9.0.1" status of 424626,
is/was the basis for the 3.0.1 ReleaseNotes wording.

A couple days ago I installed Ubuntu 7.0.4 i386 (Desktop) from scratch
using a CD sold by linuxcentral. Then, used synaptic etc. to obtain
and apply all updates. Hence, 'uname -a' now says "2.6.20-17-generic
#2 SMP Thu Jul 10 00:05:43 UTC 2008 i686 GNU/Linux".

Subsequently downloaded and installed Firefox 3.0.1 manually; because
the native Ubuntu mechanisms do not understand that any Firefox rev
higher than 2.* might exist and warrant downloading/installation.

I am at home, using a dialup land line connection to my ISP, and ppp
(via 'wvdial'). There is no other computer, telephone or network
gear in my home. The linux is "out of the box" except for installing
the aforementioned up-to-current-revs patches. I don't know whether
NM is running, nor how to determine whether it is running. I am a
"simple end user" when it comes to linux.

When I startup Firefox, it is in Offline mode. I am forced to uncheck
the "Offline" box in the menu, else Firefox will not be able to access
internet sites. This behavior, I believe, is exactly the unwanted
behavior described in the Summary line for 424646. That is why I say,
it has not been fixed.

If "you" (the maintainer(s)) understand that the unwanted behavior
is still occurring, please amend the ReleaseNotes and the underlying
status code for 424646, to reflect that the bug has not been fixed.
Or let me know where/how to  file an issue directly to someone who
maintains the release notes, if that is the usual mechanism for correcting them.

It appears, though, that possibly the maintainer(s) may be declining to
fix the bug under the premise that "it does not deserve fixing" -- or
however you might summarize that kind of argument -- and that leaving
users in the situation of working around the bug by either unchecking
the Offline box, or editing about:config (too dangerous for an
simple end user?) may be the most advisable approach for now.
I don't happen to agree with that view. But even if you hold that view,
I don't believe it is possible to justify calling the bug "fixed".
It has not been fixed!
Blocks: 449054
If this bug is fixed, can we get confirmation, and change resolution of FIXED? @Steve, I am referencing your bug, Bug 449054 
(In reply to comment #109)
> If this bug is fixed, can we get confirmation, and change resolution of FIXED?
> @Steve, I am referencing your bug, Bug 449054 
> 

In reply to comment #109 about bug 424626 and comments #1 and #2 about bug 449054 (which seeks to get the documentation to reflect the fact that this bug has not been fixed):

Subsequent to filing 424626 about the bug behavior being observable under 
Ubuntu 7.0.4, I have installed Ubuntu 8.0.4 and updated it to where 'uname -r' says " 2.6.24-19-generic #1 SMP Fri Jul 11 23:41:49 UTC 2008 i686 GNU/Linux".
Likewise updated all other items that are understood by the update manager
as being available to grab and install.

Same buggy behavior is still observable, there, for Firefox 3.0.1. 

Had to install Firefox 3.0.1 manually, as the native Ubuntu mechanism does not yet understand that 3.0.1 exists.

I agree with Steve that applications should use (established!) protocols and standards to talk to the OS. They shouldn't try to rely on software which is far from a stable and complete state. INstead they should use the right level of protocols.

Network manager is just a tool, to ease connecting to the outside world, but it is much too high level to get a reliable statement from it if a connection to some sites is possible or not.

If NM controls the default route, it is even possible to connect to some sites via non-default routes, e.g. to allow only some sites for children etc.

So IMHO asking NM is wrong.

I think to detect complete isolation from outer network you can only ask the same level of APIs you are using to communicate.
If NM would ask this same low level API it might be reasonable to ask NM instead, but you should have a guaranty that it does work this way.

I strongly believe that automatisms should be nearly perfect and well tested before you drop them as a default on users. Especially if they cannot be disabled. Microsoft has often made this mistake and I have already spent a lot of time to these kind of problems. I don't want to see this behaviour in linux.

I am mainly using linux, because I don't want to be forced to do things the way the producer thinks. I am probably not in mainstream, so this is very important for me.

As someone else already wrote, FF3 makes an automatic decision about the offline state and overrides the user's choice. I don't think it is even necessary to have this automatic behaviour.

Instead FF3 could ask the user if he wants to go offline, when a minimum count of connection attempts failed. Then a user gets the chance to correct the network state before continuing. This way he doesn't need to reload all those tabs, just because the network fails for a moment. Also, if there are tabs which failed to load and the user disables offline mode, FF3 could reload those tabs itself (or ask before).
Clearly NetworkManager can't be trusted, so we have to disable this by default. If distros feel that their NM can be trusted, they can turn this back on.

This sucks, but there is nothing else we can do right now. The Linux platform just has no efficient, reliable way to get this information.
Attachment #336272 - Flags: review?(caillon)
(In reply to comment #111)
> Network manager is just a tool, to ease connecting to the outside world, but
> it is much too high level to get a reliable statement from it if a connection
> to some sites is possible or not.

NetworkManager claims to offer such an API. If there's a way to use lower-level APIs to get the information, it could use those APIs to make its API reliable. If there is no way to make its API reliable, it shouldn't offer the API.
I don't understand why there is still an insistense on this bug being an edge case.

There are many situations where NM has to be disabled or ignored. PPP, rutilt, manual configuration (static IP).

I find that relying on an optional component is quite heavy handed.

Work Offline should be a user option. not automatically set up.

Alternativelly there should be an option (not hidden) where the user can check if he/she wants to rely on the NM for connectivity.

Having it always check the NM is missguided. This is a bug.
Attachment #336272 - Flags: review?(caillon) → review?(dcamp)
(In reply to comment #114)
> I don't understand why there is still an insistense on this bug being an edge
> case.
>
> There are many situations where NM has to be disabled or ignored. PPP, rutilt,
> manual configuration (static IP).

Not sure about PPP, but the other situations are edge cases. However, breaking things by default for those cases is not acceptable, so I'm planning to disable NM usage by default.

> I find that relying on an optional component is quite heavy handed.

1) There is no "non-optional" component capable of doing what we need. That is a weakness of the Linux (or GTK if you prefer) platform.
2) We don't rely on NetworkManager in order to operate. All we rely on is that IF it is present, it tells us the truth. Unfortunately it doesn't; that's just a fixable bug in Networkmanager and not our fault. Of course since the bug isn't fixed, it is our fault to trust NetworkManager, so we should stop doing that.

> Work Offline should be a user option. not automatically set up.

No, it's very useful to have it work automatically. We have that for Windows and people want it on all platforms. I'm 100% sure that when we turn this off by default for Linux, people will start to complain that Firefox doesn't have feature parity on Linux and so obviously Mozilla hates Linux.

> Alternativelly there should be an option (not hidden) where the user can check
> if he/she wants to rely on the NM for connectivity.

Most people who need that would never find it.

> Having it always check the NM is missguided. This is a bug.

Now that I know more about the state of NetworkManager, I agree.
Attachment #336272 - Flags: review?(dcamp) → review+
I don't understand, why offline mode should be switched automatically...

What is the benefit of doing this automatically?

I think most people are always online and therefore don't want firefox to go to offline mode silently. Loosing connection is usually unintentionally and shouldn't be punished by reloading all pages etc.

I think it is irrelevant, whether you ARE online (or don't), but instead it is relevant if you WANT to be online (or don't).
I assume, network-manager doesn't tell your intention but only tells the current online state, intentionally or not.

So, as a conclusion, this information doesn't tell the right thing and therefore shouldn't be used.

Feel free to correct my assumptions...
Pushed f2f2446cf2de.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
(In reply to comment #116)
> What is the benefit of doing this automatically?

It's very convenient when a machine loses or acquires network access often.

> I think most people are always online and therefore don't want firefox to go
> to offline mode silently.

Not true at all. Mobile people with laptops frequently transition between online and offline. It's stupid to have to manually tell Firefox when this is happening when the system already knows.

> Loosing connection is usually unintentionally and
> shouldn't be punished by reloading all pages etc.

We don't reload all pages when changing online/offline state.

> I think it is irrelevant, whether you ARE online (or don't), but instead it is
> relevant if you WANT to be online (or don't).
> I assume, network-manager doesn't tell your intention but only tells the
> current online state, intentionally or not.

An application that can either work locally or contact a server, such as an offline-enabled Web email application, needs to know whether you ARE online, not whether you WANT to be online, in order to choose the best strategy for saving email, for example. The same goes for Firefox choosing whether to try to load pages or just get them from the cache. Knowing whether you "want" to be online is not useful at all.
> Mobile people with laptops frequently transition between
> online and offline. It's stupid to have to manually tell Firefox when this is
> happening when the system already knows.

ok, I understand and accept this use case

Then we have two different situations, which require two different switches in the UI.

> We don't reload all pages when changing online/offline state.

that's exactly the problem I'm referring to here. When firefox goes online again I have to reload all relevant pages manually, because cache contents doesn't help me in many cases (think of bug-trackers, bank accounts, etc.).

So, in my use case (always wanting to be online with unwanted interruptions) firefox should inform me when failing to load a page and should NOT go offline but instead should try to load the missing page again when the connection comes back. In this case the "WANT a connection" state is relevant and after that also the "HAVE a connection" state.

so we have four situations:

connection  firefox
WANT HAVE   action
 x    x     load page from net
 x    -     wait for connection, perhaps load page from cache and inform user
 -    x     load page from cache?
 -    -     load page from cache

the WANT state could be the inverted offline flag in firefox
This bug still exists. I am running FF 3.0.4 on Fedora 9 and this is still an issue on my system. NM does not control my network connections. Setting toolkit.networkmanager.disable to true corrects the problem.
Another way around this on Fedora 9 is to use system-config-network and check the box for the network connection to allow it to be managed by NetworkManager.
i have this issue yet, in mandriva 2009 and firefox 3.0.4, and i don't use networkmanager. hope you'll resolve this bug soon, it's very annoying. 

Bye
Marcello
Marcello, you can now disable offline detection by going to about:config and setting toolkit.networkmanager.disable to true.
When I set the pref "toolkit.networkmanager.disable" to true in about:config, it actually works - no more offline at startup.
Thanks!
Why is this 'feature' even there in the first place?  The user should never have to explicitly switch between online/offline modes.  The browser can either resolve and load a site or it can't, and when it can't /then/ show a warning regarding it.  Forcing the user to manually re-enable the ability to browse every time their connection goes up or down is just idiotic.  I'm guessing this entire concept is just legacy nonsense and has no actual logical /practical/ rationale associated with it any longer.
can't load a live bookmark, homepage, or other external site > assume offline mode.

user tries to view an external site when in offline mode > assume online mode, try, and either leave online mode if successful or warn the user and revert to offline if not.

otherwise > assume online mode.

This flow would make using firefox on the plethora of portable 3g/2.5g/2g/wifi connected devices SO much smoother.  Sure you can disable this behavior by telling firefox, through about:config, to ignore NetworkManager, but do you think average Joe Blogs will have any clue how to do this or where to find the instructions to do it?  </2_cents>
(In reply to comment #126)
> When I set the pref "toolkit.networkmanager.disable" to true in about:config,
> it actually works - no more offline at startup.
> Thanks!

I had done that some time ago, but when I upgraded from Fedora 9 to Fedora 10 (which installed Fedora/3.0.5-1.fc10 Firefox/3.0.5) I found Firefox had reverted to the old behaviour. I had completely forgotten how to fix this and it took me some time to rediscover it.

The facility to switch off the behaviour (going offline and preventing old web pages from being redisplayed) really should be one of the items in the preference menu which will be preserved in the user's files.

I use Firefox as a substantial extension of my working memory. I usually have several windows open (anything between 3 and about 20) each of which can have several tabs. I don't use networkmanager because my desktop PC is connected by cable to a router using a static address. If I have to restart firefox e.g. after booting, or after suspend/resume (I use tuxonice) it is a real pain to have to go through every tab in every window clicking 'try again', after deselecting 'work offline'. Who dreamed up that mechanism?

For people who have not learnt how to use "about:config", and who use multiple tabs as I do, it is essential either to make everything reconnect automatically when 'work offline' is deselected, or to have an adjacent button labelled 'retry all'. or 'reconnect all' which works only when offline is deslected.

(Ideally that should be in addition to a preference to turn off checking of network connectivity. It's a bit pointless anyway, because there can be a network failure at many locations, e.g. at the service provider, or beyond, and whether networkmanager does or does not think there is a successful connection can be irrelevant in that case.)

[Incidentally, I am finding that Firefox causes a much smaller load since I switched to Fedora 10.]
For a work-around: See Comment #28 From  Mike Shaver   2008-05-26 11:45:21 PST above:

Right-click any tab, select 'Reload All Tabs'

For me the change in about:com is the only solution.

Living high up in the Andes Mountains and using a GPRS dongle, during the day time I have about 30 Kbit/s at best. Reloading 10-12 tabs often took half an hour.
decent offline support is really required to do enhanced stuff like pausing/resuming downloads; saying "dump offline integration with linux desktop" is not really innovation. Instead we should tackle the underlying issues that cause the bad experience here imo.
You mean I should fix Network Manager and take responsibility get the updates pushed out to all users?
Note that it's preffed off so if your distro has a working NetworkManager you can easily turn it back on.
Roc, do we have any requirements NM has to fulfill before we can enable this by default again?

Maybe we can probe for the running version and enable it by default if NM is 0.7 or later is used?
No, NM 0.7 will not solve the problem. AFAIK it can't manage all possible network interfaces, and even if it could there will still be people who choose to run NM but have some active interfaces not managed by NM, no matter how much we wish they wouldn't. And if we treat StateChange messages as reliable they will blame Firefox for being broken.

The NM issues are covered pretty well here: http://bugzilla.gnome.org/show_bug.cgi?id=418745#c13
I agree with Martin's comment there and have just attached a followup comment of my own, which echoes what I've already said in this bug. It seems to me that NM could enumerate the active interfaces (like ifconfig does) and detect when there are interfaces in that list that it isn't managing (and aren't loopback), and in that case, refrain from sending StateChange messages.
I don't see disabling NetworkManager as a realistic solution.  I don't want to have to change configuration on my laptop every time I move from a wired to wireless situation.  I also don't see any good reason for making this check in the first place.  Let me disable the check and I promise I'll never miss it.

While I'm at it, my other annoyance:  Why can't Firefox simply ASK if I want to accept cookies or javascript from a particular site and store a record of the choice?  (Sorry if this is the wrong place for this.  I'm new here and having difficulty finding my way around.)
jkohler2 added the following comment to Launchpad bug report 191889:

I am using Ubuntu 10.04 and a recent fire fox version.  When  I use my Dial-up 
program, Gnome-ppp I still need to uncheck the "work offline" box under the file pull-down menu


John

-- 
http://launchpad.net/bugs/191889
Neill_R added the following comment to Launchpad bug report 191889:

 <info> Unmanaged Device found; state CONNECTED forced.

I am running Ubuntu server 12.04 LTS with ubuntu-desktop installed. The eth0 device is not managed by NM. I use NM to connect my 3g Mobile Broardband USB modem to the internet.  I also use firestarter to provision (Internet Connection Sharing). As of this moment I see no problems. Either when I use my 3G modem or I plug the eth0 into a router to gain Internet access.
 

-- 
http://launchpad.net/bugs/191889
Comment on attachment 322833 [details] [diff] [review]
Disable DBUS support if NetworkManager 0.7 is not present

Per comments 61 - 72 removing what I understand to be an obsolete review request on a long-old patch. If I have miss-understood the patch is still needed, please file a new bug and attach a fresh patch there. Thanks.
Attachment #322833 - Flags: review?(caillon)
Joni-Pekka Kurronen added the following comment to Launchpad bug report 191889:

Same here whit 12.5 LTS 64 bit,... but it's anoying
that syslog fill's whit below shit,...

=====
Dec  2 23:28:14 kurrola kernel: [28963.624076] Unknown OutputIN= OUT=lxcbr0 SRC=10.0.3.1 DST=10.0.3.255 LEN=316 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=631 DPT=631 LEN=296 
Dec  2 23:28:21 kurrola NetworkManager[2085]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec  2 23:28:23 kurrola NetworkManager[2085]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec  2 23:28:31 kurrola NetworkManager[2085]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec  2 23:28:33 kurrola NetworkManager[2085]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec  2 23:28:41 kurrola NetworkManager[2085]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec  2 23:28:43 kurrola NetworkManager[2085]: <info> Unmanaged Device found; state CONNECTED forced. (see http://bugs.launchpad.net/bugs/191889)
Dec  2 23:28:45 kurrola kernel: [28994.926798] Unknown OutputIN= OUT=lxcbr0 SRC=10.0.3.1 DST=10.0.3.2

-- 
http://launchpad.net/bugs/191889
You need to log in before you can comment on or make changes to this bug.