Closed Bug 791626 Opened 12 years ago Closed 11 years ago

offline status not updated by Firefox 15 in Fedora 17

Categories

(Core :: Networking, defect)

15 Branch
x86_64
Linux
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla21

People

(Reporter: fabrice, Assigned: stransky)

References

Details

Attachments

(3 files)

With Firefox 15 and Fedora 17, I see a problem with the offline status of Firefox not being updated according to the status reported by NetworkManager, even when network.manage-offline-status is set to true.

I suggest the attached patch

The idea is to change the mManageOfflineStatus variable only when the user toggles the network.manage-offline-status setting in about:config.

Specifically I think we should not set it to off in nsIOService::InitializeNetworkLinkService() when the mNetworkLinkService is not initialized yet, because 1/ there's no way for the user to know that the value has changed (network.manage-offline-status in about:config doesn't reflect the modification in that case), and 2/ there's no possibility for the variable to come back to the value true, except if the user manually toggles twice the network.manage-offline-status setting.

Similarly in the firefox interface (browser.js). If mManageOfflineStatus is on, and network is offline, firefox status will be offline too. If the user want to access some URL locally (http://localhost/...), he will set firefox online. Later, when the network on his box is back online, it seems natural that firefox status still follows the box connectivity status, which will be possible only if mManageOfflineStatus stays on.
Is this bug a regression?  Does this work in some previous version of Firefox?
I think it's a regression. I tested various versions of firefox/xulrunner on a Fedora 16 (taken from the buildsystem http://koji.fedoraproject.org/koji), and it stopped working between 9.0.1 and 10.0.
(In reply to Fabrice Bellet from comment #2)
> it stopped working between 9.0.1 and 10.0.

Could be a regression from bug 627672.  We already fixed one regression caused by that patch in bug 720320.

However, I think you just fail to initialize the network link service.

I have to ask, since it is not understandable from your report, what is the actual problem.  Is it that Firefox is still online even there is no net connection according the Net Manager or that Firefox is offline (or drops offline) and never returns to online even a network connection comes up?
Blocks: 627672
(In reply to Honza Bambas (:mayhemer) from comment #3)
> I have to ask, since it is not understandable from your report, what is the
> actual problem.  Is it that Firefox is still online even there is no net
> connection according the Net Manager or that Firefox is offline (or drops
> offline) and never returns to online even a network connection comes up?

yes, Firefox stays online when there's no network connection according to the NetworkManager.
I'm not able to reproduce this bug on my Fedora 17 installation with enabling/disabling the only wired card on the system using the the network manager (Gnome 3.4.2).  The code works as expected.

On my machine, we first get nsXREDirProvider::DoStartup -> nsIOService::SetManageOfflineStatus(true) that sets mManageOfflineStatus to true and then (re)tries to instantiate the network link service what succeeds.  These steps put necko to an offline-state-managed mode correctly.

It looks like toolkit/system/dbus/nsNetworkManagerListener.cpp gets instantiated later or not at all on your machine.  After "profile-do-change", that is triggered later after nsXREDirProvider::DoStartup we stop trying to instantiate networking link service for the whole browser lifetime.

I personally don't think your patch would be of any help with it.  

Can you confirm you are getting calls of nsNetworkManagerListener::UpdateNetworkStatus when your net config state changes?

If not, can you please apply this small patch and then when firefox is running switch the "network.manage-offline-status" to false and then back to true and retry?

diff --git a/netwerk/base/src/nsIOService.cpp b/netwerk/base/src/nsIOService.cpp
--- a/netwerk/base/src/nsIOService.cpp
+++ b/netwerk/base/src/nsIOService.cpp
@@ -1057,16 +1057,17 @@ nsIOService::SetManageOfflineStatus(bool
     // TrackNetworkLinkStatusForOffline().  When there is no network link
     // available during call to InitializeNetworkLinkService(), application is
     // put to offline mode.  And when we change mMangeOfflineStatus to false
     // on the next line we get stuck on being offline even though the link
     // becomes later available.
     bool wasManaged = mManageOfflineStatus;
     mManageOfflineStatus = aManage;

+    mNetworkLinkServiceInitialized = false;
     InitializeNetworkLinkService();

     if (mManageOfflineStatus && !wasManaged) {
         rv = TrackNetworkLinkStatusForOffline();
         if (NS_FAILED(rv))
             mManageOfflineStatus = false;
     }
     return rv;


If so, it would mean libdbusservice.so with network link service gets loaded even later then before "profile-do-change".
Fabrice, see comment 5 please.
Flags: needinfo?(fabrice)
(In reply to Honza Bambas (:mayhemer) from comment #5)
> I'm not able to reproduce this bug on my Fedora 17 installation with
> enabling/disabling the only wired card on the system using the the network
> manager (Gnome 3.4.2).  The code works as expected.

my setup changed a bit since I initially reported the bug. I'm now running firefox-17.0.1 on the upcoming Fedora 18. But I confirm that the bug still exists in my case (NetworkManager-0.9.7.0-11.git20121004.fc18.x86_64). I removed the directory ~/.mozilla before the test.

> 
> On my machine, we first get nsXREDirProvider::DoStartup ->
> nsIOService::SetManageOfflineStatus(true) that sets mManageOfflineStatus to
> true and then (re)tries to instantiate the network link service what
> succeeds.  These steps put necko to an offline-state-managed mode correctly.

In my case, nsIOService::SetManageOfflineStatus(true) is called earlier:

#0  nsIOService::SetManageOfflineStatus (this=0x7ffff6cad100, aManage=true) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:1094
#1  0x00007ffff229f24a in nsIOService::PrefsChanged (this=0x7ffff6cad100, prefs=0x7fffdf6fccd0, pref=0x0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:869
#2  0x00007ffff229ca3f in nsIOService::Init (this=0x7ffff6cad100) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:197
#3  0x00007ffff229cfd0 in nsIOService::GetInstance () at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:300
#4  0x00007ffff22765eb in nsIOServiceConstructor (aOuter=0x0, aIID=..., aResult=0x7fffffff8230) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/build/nsNetModule.cpp:51
#5  0x00007ffff3ca81f3 in mozilla::GenericFactory::CreateInstance (this=0x7fffd7e35040, aOuter=0x0, aIID=..., aResult=0x7fffffff8230) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/objdir/xpcom/build/GenericFactory.cpp:16
#6  0x00007ffff3d0118a in nsComponentManagerImpl::CreateInstanceByContractID (this=0x7ffff6c994e0, aContractID=0x7ffff4a0b4e8 "@mozilla.org/network/io-service;1", aDelegate=0x0, aIID=..., aResult=0x7fffffff8230) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:1031
#7  0x00007ffff3d01fde in nsComponentManagerImpl::GetServiceByContractID (this=0x7ffff6c994e0, aContractID=0x7ffff4a0b4e8 "@mozilla.org/network/io-service;1", aIID=..., result=0x7fffffff8348) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:1433
#8  0x00007ffff3c99298 in CallGetService (aContractID=0x7ffff4a0b4e8 "@mozilla.org/network/io-service;1", aIID=..., aResult=0x7fffffff8348) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/objdir/xpcom/build/nsComponentManagerUtils.cpp:62
#9  0x00007ffff3c997b4 in nsGetServiceByContractID::operator() (this=0x7fffffff8330, aIID=..., aInstancePtr=0x7fffffff8348) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/objdir/xpcom/build/nsComponentManagerUtils.cpp:246
#10 0x00007ffff2da9709 in nsCOMPtr<nsIIOService>::assign_from_gs_contractid (this=0x7fffffff8380, gs=..., aIID=...) at ../../dist/include/nsCOMPtr.h:1184
#11 0x00007ffff2da8d6f in nsCOMPtr<nsIIOService>::nsCOMPtr (this=0x7fffffff8380,gs=...) at ../../dist/include/nsCOMPtr.h:586
#12 0x00007ffff3cacc83 in mozilla::services::GetIOService () at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/build/ServiceList.h:14
#13 0x00007ffff2234b0b in do_GetIOService (error=0x7fffffff83fc) at ../../dist/include/nsNetUtil.h:85
#14 0x00007ffff2234b6e in net_EnsureIOService (ios=0x7fffffff8428, grip=...) at../../dist/include/nsNetUtil.h:125
#15 0x00007ffff2234bd9 in NS_NewURI (result=0x7fffffff8778, spec=..., charset=0x0, baseURI=0x0, ioService=0x0) at ../../dist/include/nsNetUtil.h:140
#16 0x00007ffff3cb595e in nsChromeRegistry::ManifestProcessingContext::GetManifestURI (this=0x7fffffff8750) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/chrome/src/nsChromeRegistryChrome.cpp:756
#17 0x00007ffff3cb59a5 in nsChromeRegistry::ManifestProcessingContext::ResolveURI (this=0x7fffffff8750, uri=0x7fffd7cdec13 "en-US/locale/en-US/necko/") at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/chrome/src/nsChromeRegistryChrome.cpp:773
#18 0x00007ffff3cb5ce0 in nsChromeRegistryChrome::ManifestLocale (this=0x7fffdf6432d0, cx=..., lineno=1, argv=0x7fffffff8700, platform=false, contentaccessible=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/chrome/src/nsChromeRegistryChrome.cpp:845
#19 0x00007ffff3d08b1b in ParseManifest (type=NS_COMPONENT_LOCATION, file=..., buf=0x7fffd7cdec00 "locale", aChromeOnly=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/ManifestParser.cpp:635
#20 0x00007ffff3cff798 in nsComponentManagerImpl::RegisterManifest (this=0x7ffff6c994e0, aType=NS_COMPONENT_LOCATION, aFile=..., aChromeOnly=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:497
#21 0x00007ffff3cff868 in nsComponentManagerImpl::ManifestManifest (this=0x7ffff6c994e0, cx=..., lineno=4, argv=0x7fffffff8eb0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:510
#22 0x00007ffff3d08c17 in ParseManifest (type=NS_COMPONENT_LOCATION, file=..., buf=0x7fffdf6ff000 "manifest", aChromeOnly=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/ManifestParser.cpp:646
#23 0x00007ffff3cff798 in nsComponentManagerImpl::RegisterManifest (this=0x7ffff6c994e0, aType=NS_COMPONENT_LOCATION, aFile=..., aChromeOnly=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:497
#24 0x00007ffff3d002d1 in nsComponentManagerImpl::RereadChromeManifests (this=0x7ffff6c994e0, aChromeOnly=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:665
#25 0x00007ffff3cfefbf in nsComponentManagerImpl::Init (this=0x7ffff6c994e0) at/home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:365
#26 0x00007ffff3cab030 in NS_InitXPCOM2_P (result=0x7ffff6c8bf60, binDirectory=0x7ffff6c7b480, appFileLocationProvider=0x7fffffff97a0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/build/nsXPComInit.cpp:466
#27 0x00007ffff2236e7f in ScopedXPCOMStartup::Initialize (this=0x7ffff6c8bf60) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:1174
#28 0x00007ffff2240772 in XREMain::XRE_main (this=0x7fffffff9760, argc=1, argv=0x7fffffffdb48, aAppData=0x7ffff6c42480) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3884
#29 0x00007ffff2240a44 in XRE_main (argc=1, argv=0x7fffffffdb48, aAppData=0x7ffff6c42480, aFlags=0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3965
#30 0x0000000000402920 in main ()

This call enters in function InitializeNetworkLinkService(), and at line 280, mManageOfflineStatus is set to false here, altough SetManageOfflineStatus() was called with aManage=true:

#0  nsIOService::InitializeNetworkLinkService (this=0x7ffff6cad100) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:280
#1  0x00007ffff22a00be in nsIOService::SetManageOfflineStatus (this=0x7ffff6cad100, aManage=true) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:1107
#2  0x00007ffff229f24a in nsIOService::PrefsChanged (this=0x7ffff6cad100, prefs=0x7fffdf6fccd0, pref=0x0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:869
[...]

Later, nsXREDirProvider::DoStartup() is called, but nsIOService::SetManageOfflineStatus() is not called inside this function:

Breakpoint 1, nsXREDirProvider::DoStartup (this=0x7fffffff97a0) at /home/bellet/
Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit
/xre/nsXREDirProvider.cpp:739
(gdb) bt
#0  nsXREDirProvider::DoStartup (this=0x7fffffff97a0) at /home/bellet/Developmen
t/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsXRE
DirProvider.cpp:739
#1  0x00007ffff223fd8a in XREMain::XRE_mainRun (this=0x7fffffff9760) at /home/be
llet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/to
olkit/xre/nsAppRunner.cpp:3690
#2  0x00007ffff22407fb in XREMain::XRE_main (this=0x7fffffff9760, argc=1, argv=0
x7fffffffdb48, aAppData=0x7ffff6c42480) at /home/bellet/Development/fedora/local
/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:388
9
#3  0x00007ffff2240a44 in XRE_main (argc=1, argv=0x7fffffffdb48, aAppData=0x7fff
f6c42480, aFlags=0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulr
unner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3965
#4  0x0000000000402920 in main ()


> 
> It looks like toolkit/system/dbus/nsNetworkManagerListener.cpp gets
> instantiated later or not at all on your machine.  After
> "profile-do-change", that is triggered later after
> nsXREDirProvider::DoStartup we stop trying to instantiate networking link
> service for the whole browser lifetime.

yes. it seems that it gets instantiated after "profile-do-change", with this backtrace:

#0  nsNetworkManagerListener::Init (this=0x7fffd4022670) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/system/dbus/nsNetworkManagerListener.cpp:67
#1  0x00007fffd6fe07db in nsNetworkManagerListenerConstructor (aOuter=0x0, aIID=..., aResult=0x7fffffff91b0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/system/dbus/nsDBusModule.cpp:25
#2  0x00007ffff3ca81f3 in mozilla::GenericFactory::CreateInstance (this=0x7fffd4039040, aOuter=0x0, aIID=..., aResult=0x7fffffff91b0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/objdir/xpcom/build/GenericFactory.cpp:16
#3  0x00007ffff3d0118a in nsComponentManagerImpl::CreateInstanceByContractID (this=0x7ffff6c994e0, aContractID=0x7ffff44ad8f8 "@mozilla.org/network/network-link-service;1", aDelegate=0x0, aIID=..., aResult=0x7fffffff91b0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:1031
#4  0x00007ffff3d01fde in nsComponentManagerImpl::GetServiceByContractID (this=0x7ffff6c994e0, aContractID=0x7ffff44ad8f8 "@mozilla.org/network/network-link-service;1", aIID=..., result=0x7fffffff92c8) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/components/nsComponentManager.cpp:1433
#5  0x00007ffff3c99298 in CallGetService (aContractID=0x7ffff44ad8f8 "@mozilla.org/network/network-link-service;1", aIID=..., aResult=0x7fffffff92c8) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/objdir/xpcom/build/nsComponentManagerUtils.cpp:62
#6  0x00007ffff3c99808 in nsGetServiceByContractIDWithError::operator() (this=0x7fffffff9330, aIID=..., aInstancePtr=0x7fffffff92c8) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/objdir/xpcom/build/nsComponentManagerUtils.cpp:256
#7  0x00007ffff22a23b3 in nsCOMPtr<nsINetworkLinkService>::assign_from_gs_contractid_with_error (this=0x7ffff6cad160, gs=..., aIID=...) at ../../../dist/include/nsCOMPtr.h:1194
#8  0x00007ffff22a1388 in nsCOMPtr<nsINetworkLinkService>::operator= (this=0x7ffff6cad160, rhs=...) at ../../../dist/include/nsCOMPtr.h:680
#9  0x00007ffff229cf04 in nsIOService::InitializeNetworkLinkService (this=0x7ffff6cad100) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:271
#10 0x00007ffff229f889 in nsIOService::Observe (this=0x7ffff6cad100, subject=0x0, topic=0x7ffff44a06d5 "profile-do-change", data=0x7ffff44a0b90 <nsXREDirProvider::DoStartup()::kStartup>) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/netwerk/base/src/nsIOService.cpp:973
#11 0x00007ffff3cc2c5f in nsObserverList::NotifyObservers (this=0x7fffd43f9378,aSubject=0x0, aTopic=0x7ffff44a06d5 "profile-do-change", someData=0x7ffff44a0b90<nsXREDirProvider::DoStartup()::kStartup>) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/ds/nsObserverList.cpp:99
#12 0x00007ffff3cc4739 in nsObserverService::NotifyObservers (this=0x7fffdf6f61f0, aSubject=0x0, aTopic=0x7ffff44a06d5 "profile-do-change", someData=0x7ffff44a0b90 <nsXREDirProvider::DoStartup()::kStartup>) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/ds/nsObserverService.cpp:149
#13 0x00007ffff224a9d8 in nsXREDirProvider::DoStartup (this=0x7fffffff97a0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsXREDirProvider.cpp:768
#14 0x00007ffff223fd8a in XREMain::XRE_mainRun (this=0x7fffffff9760) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3690
#15 0x00007ffff22407fb in XREMain::XRE_main (this=0x7fffffff9760, argc=1, argv=0x7fffffffdb48, aAppData=0x7ffff6c42480) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3889
#16 0x00007ffff2240a44 in XRE_main (argc=1, argv=0x7fffffffdb48, aAppData=0x7ffff6c42480, aFlags=0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3965
#17 0x0000000000402920 in main ()

> 
> I personally don't think your patch would be of any help with it.  
> 
> Can you confirm you are getting calls of
> nsNetworkManagerListener::UpdateNetworkStatus when your net config state
> changes?

yes, I confirm that I get calls to nsNetworkManagerListener::UpdateNetworkStatus() each time the network-manager status changes:

Breakpoint 13, nsNetworkManagerListener::UpdateNetworkStatus (this=0x7fffd4022670, msg=0x7fffd41e76c0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/system/dbus/nsNetworkManagerListener.cpp:165

the initial call to nsNetworkManagerListener::UpdateNetworkStatus() occurs after nsXREDirProvider::DoStartup() with this backtrace:

(gdb) bt
#0  nsNetworkManagerListener::UpdateNetworkStatus (this=0x7fffd4029b20, msg=0x7fffd3a36040) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/system/dbus/nsNetworkManagerListener.cpp:165
#1  0x00007fffd6fe1f73 in NetworkStatusNotify (pending=0x7fffd41fe380, user_data=0x7fffd4029b20) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/system/dbus/nsNetworkManagerListener.cpp:86
#2  0x00007fffefb6085a in complete_pending_call_and_unlock () from /lib64/libdbus-1.so.3
#3  0x00007fffefb63923 in dbus_connection_dispatch () from /lib64/libdbus-1.so.3
#4  0x00007fffefda3c55 in message_queue_dispatch () from /lib64/libdbus-glib-1.so.2
#5  0x00007fffef62aa75 in g_main_dispatch (context=0x7ffff6c2cbe0) at gmain.c:2715
#6  g_main_context_dispatch (context=context@entry=0x7ffff6c2cbe0) at gmain.c:3219
#7  0x00007fffef62ada8 in g_main_context_iterate (context=context@entry=0x7ffff6c2cbe0, block=block@entry=0, dispatch=dispatch@entry=1, self=<optimized out>) atgmain.c:3290
#8  0x00007fffef62ae64 in g_main_context_iteration (context=0x7ffff6c2cbe0, may_block=0) at gmain.c:3351
#9  0x00007ffff38fbded in nsAppShell::ProcessNextNativeEvent (this=0x7fffdf61c4e0, mayWait=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/widget/gtk2/nsAppShell.cpp:131
#10 0x00007ffff3926fa3 in nsBaseAppShell::DoProcessNextNativeEvent (this=0x7fffdf61c4e0, mayWait=false, recursionDepth=0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/widget/xpwidgets/nsBaseAppShell.cpp:139
#11 0x00007ffff392734b in nsBaseAppShell::OnProcessNextEvent (this=0x7fffdf61c4e0, thr=0x7ffff6c1e710, mayWait=false, recursionDepth=0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/widget/xpwidgets/nsBaseAppShell.cpp:280
#12 0x00007ffff3d0d56c in nsThread::ProcessNextEvent (this=0x7ffff6c1e710, mayWait=false, result=0x7fffffff93af) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/xpcom/threads/nsThread.cpp:586
#13 0x00007ffff3c9f931 in NS_ProcessNextEvent_P (thread=0x7ffff6c1e710, mayWait=false) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/objdir/xpcom/build/nsThreadUtils.cpp:220
#14 0x00007ffff3a7e04b in mozilla::ipc::MessagePump::Run (this=0x7fffdf66aa00, aDelegate=0x7ffff6ceff90) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/ipc/glue/MessagePump.cpp:82
#15 0x00007ffff3d5eb2b in MessageLoop::RunInternal (this=0x7ffff6ceff90) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/ipc/chromium/src/base/message_loop.cc:208
#16 0x00007ffff3d5eabc in MessageLoop::RunHandler (this=0x7ffff6ceff90) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/ipc/chromium/src/base/message_loop.cc:201
#17 0x00007ffff3d5ea95 in MessageLoop::Run (this=0x7ffff6ceff90) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/ipc/chromium/src/base/message_loop.cc:175
#18 0x00007ffff3927040 in nsBaseAppShell::Run (this=0x7fffdf61c4e0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/widget/xpwidgets/nsBaseAppShell.cpp:163
#19 0x00007ffff364bcd2 in nsAppStartup::Run (this=0x7fffd7d56510) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/components/startup/nsAppStartup.cpp:273
#20 0x00007ffff224050b in XREMain::XRE_mainRun (this=0x7fffffff9760) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3812
#21 0x00007ffff22407fb in XREMain::XRE_main (this=0x7fffffff9760, argc=1, argv=0x7fffffffdb48, aAppData=0x7ffff6c42480) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3889
#22 0x00007ffff2240a44 in XRE_main (argc=1, argv=0x7fffffffdb48, aAppData=0x7ffff6c42480, aFlags=0) at /home/bellet/Development/fedora/local/xulrunner/F-18/xulrunner-17.0.1/mozilla-release/toolkit/xre/nsAppRunner.cpp:3965
#23 0x0000000000402920 in main ()

> 
> If not, can you please apply this small patch and then when firefox is
> running switch the "network.manage-offline-status" to false and then back to
> true and retry?
> 
> diff --git a/netwerk/base/src/nsIOService.cpp
> b/netwerk/base/src/nsIOService.cpp
> --- a/netwerk/base/src/nsIOService.cpp
> +++ b/netwerk/base/src/nsIOService.cpp
> @@ -1057,16 +1057,17 @@ nsIOService::SetManageOfflineStatus(bool
>      // TrackNetworkLinkStatusForOffline().  When there is no network link
>      // available during call to InitializeNetworkLinkService(), application
> is
>      // put to offline mode.  And when we change mMangeOfflineStatus to false
>      // on the next line we get stuck on being offline even though the link
>      // becomes later available.
>      bool wasManaged = mManageOfflineStatus;
>      mManageOfflineStatus = aManage;
> 
> +    mNetworkLinkServiceInitialized = false;
>      InitializeNetworkLinkService();
> 
>      if (mManageOfflineStatus && !wasManaged) {
>          rv = TrackNetworkLinkStatusForOffline();
>          if (NS_FAILED(rv))
>              mManageOfflineStatus = false;
>      }
>      return rv;
> 
> 
> If so, it would mean libdbusservice.so with network link service gets loaded
> even later then before "profile-do-change".
Flags: needinfo?(fabrice)
And

> +    mNetworkLinkServiceInitialized = false;

helped?
I also see "/xulrunner/F-18/xulrunner-17.0.1/" in you source code path.  Are you running firefox or xulrunner actually?  If the letter, then the situation may be different because I'm testing with firefox sources (mozilla-central, application=browser).
(In reply to Honza Bambas (:mayhemer) from comment #8)
> And
> 
> > +    mNetworkLinkServiceInitialized = false;
> 
> helped?

No the patch from comment #5 didn't help. But, if I switch "network.manage-offline-status" to false and then back to true, then it works as expected, with or without the patch.
(In reply to Honza Bambas (:mayhemer) from comment #9)
> I also see "/xulrunner/F-18/xulrunner-17.0.1/" in you source code path.  Are
> you running firefox or xulrunner actually?  If the letter, then the
> situation may be different because I'm testing with firefox sources
> (mozilla-central, application=browser).

I'm really running firefox. I use the fedora rpm package spec file of xulrunner to generate a debug build for the libs (/usr/lib64/xulrunner/*.so and /usr/lib64/xulrunner/components/*.so)
I can reproduce it too, on virtual box (Fedora 18/FF 17.0.1) and on bare metal (Fedora 15/FF17). Honza, I'll investigate it.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Martin Stránský from comment #12)
> I can reproduce it too, on virtual box (Fedora 18/FF 17.0.1) and on bare
> metal (Fedora 15/FF17). Honza, I'll investigate it.

Martin, thanks!  Because I can't reproduce from some reason..
Assignee: nobody → stransky
Well, it's the same problem we had in Bug 627672, patch in Bug 720320 changed the fix. 

The problem is that SetManageOfflineStatus(TRUE) (reading network.manage-offline-status preference at startup) is called before NS_NETWORK_LINK_SERVICE is registered so the internal state mManageOfflineStatus is set to FALSE (regardless to network.manage-offline-status).

There are those problems:

- NS_NETWORK_LINK_SERVICE is unregistered when nsIOService::Init() is called so we fail in InitializeNetworkLinkService().

- SetManageOfflineStatus() is used in both cases - the initial set-up (when NS_NETWORK_LINK_SERVICE may be still down) and later when user switches network.manage-offline-status. But we need to handle those situations differently.

I think there are those options:

- to copy network.manage-offline-status to mManageOfflineStatus in nsIOService::Init() and then handle user changes as we have in SetManageOfflineStatus()

- leave current state (SetManageOfflineStatus for init and user input) but register preference listeners when we're ready (NS_NETWORK_LINK_SERVICE is also up).

Actually, can we determine somehow that the NS_NETWORK_LINK_SERVICE is ready? Is there any observer topic for component registration?
What about this one? To register observers after complete start up.
Attachment #700427 - Flags: feedback?(honzab.moz)
The patch from comment #15 works for me (firefox 18).
Martin, thanks for investigating and providing a patch.

I'd however would like to try to find some other way then moving pref observers registration and first reading of preferences that far ahead in the initialization process.  It's hard to track whether it won't cause any regression.  I want to go safe.

Martin, can you please test this patch?  It's actually based on your patch, just doing the same in a slightly different way leaving initiation of other preferences intact.  Tested on windows box that nothing is broken.

Fabrice, can you please do the test as well?

Thanks!
Attachment #701276 - Flags: feedback?(stransky)
Comment on attachment 700427 [details] [diff] [review]
register abservers after startup

If my variant doesn't work, we can try taking this, however reviewing will take some time (since we move pref reading to a later stage).
Attachment #700427 - Flags: feedback?(honzab.moz) → feedback+
(In reply to Honza Bambas (:mayhemer) from comment #17)
> Created attachment 701276 [details] [diff] [review]
> variant of Martin's patch
> 
> Fabrice, can you please do the test as well?

Yes, this other patch works too.
Comment on attachment 701276 [details] [diff] [review]
move read of "network.manage-offline-status" pref after "profile-do-change"

Hi Honza, yes it works!
Attachment #701276 - Flags: feedback?(stransky) → feedback+
Comment on attachment 701276 [details] [diff] [review]
move read of "network.manage-offline-status" pref after "profile-do-change"

- on some platforms the network link service (watching for online/offline status) is registered only after "profile-do-change"
- if we read "network.manage-offline-status" sooner, we may drop the preference back to false because of missing network link service
- moving reading and handling the preference after we have instantiated the network link service solves this problem

(Credit: Martin Stransky)
Attachment #701276 - Attachment description: variant of Martin's patch → move read of "network.manage-offline-status" pref after "profile-do-change"
Attachment #701276 - Flags: review?(cbiesinger)
Attachment #701276 - Flags: review?(cbiesinger) → review+
Comment on attachment 701276 [details] [diff] [review]
move read of "network.manage-offline-status" pref after "profile-do-change"

https://hg.mozilla.org/integration/mozilla-inbound/rev/b4b9aa0a838c
Attachment #701276 - Flags: checkin+
https://hg.mozilla.org/mozilla-central/rev/b4b9aa0a838c
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
You need to log in before you can comment on or make changes to this bug.