Closed
Bug 426932
Opened 16 years ago
Closed 16 years ago
navigator.onLine doesn't correctly update when network connectivity changes
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
VERIFIED
FIXED
People
(Reporter: aza, Assigned: dcamp)
References
Details
(Keywords: fixed1.9.1, Whiteboard: [RC2-])
Attachments
(2 files, 1 obsolete file)
15.03 KB,
patch
|
Details | Diff | Splinter Review | |
16.46 KB,
patch
|
jaas
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5 According to http://developer.mozilla.org/en/docs/Online_and_offline_events: The navigator.onLine attribute must return false if the user agent will not contact the network when the user follows links or when a script requests a remote page (or knows that such an attempt would fail)... It doesn't do so on OS X. Reproducible: Always Steps to Reproduce: 1. https://bugzilla.mozilla.org/attachment.cgi?id=220609 2. Turn off internet connectivity Actual Results: Nothing happens Expected Results: Should switch to offline. http://developer.mozilla.org/en/docs/Online_and_offline_events http://ejohn.org/blog/offline-events/
Updated•16 years ago
|
Component: General → DOM
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → Trunk
Reporter | ||
Comment 1•16 years ago
|
||
This is the bug I was talking about earlier today. I.e., that on OSX one doesn't receive the offline/online events when you physically disconnect from the internet (say by turning off your wireless).
Ugh -- too late to take this for FF3, I fear, but we should get on it ASAP to get in a 3.0.1 IMO. Offline story is...not quite as strong with this problem. :)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: wanted1.9.0.x+
Flags: blocking1.9?
Comment 3•16 years ago
|
||
Dave can you take a look at this? We'd take something for 3.0.1 or if we happen to do an RC2
Assignee: nobody → dcamp
Flags: wanted-next+
Flags: blocking1.9?
Flags: blocking1.9-
Whiteboard: [RC2?]
I don't think we should block on this. This is really a feature request that would require new code to be written --- we've never had code to detect system network connectivity on Mac. Yes, it would be nice to have, but the user can still select "Work Offline" from the File menu.
Also I'd be uncomfortable taking an implementation at this late date. We'd run the risk of changing the browser offline state at the wrong time, if there was a bug in our code or a quirk in the way OSX reports network connectivity.
Reporter | ||
Comment 6•16 years ago
|
||
I'd argue that this is not a feature request, but is instead an honest-to-goodness bug. The whole netless/offline stack is one of the touted features of Firefox 3 (http://developer.mozilla.org/en/docs/Firefox_3_for_developers), and the bug effectively breaks the ability for web authors to make cross-platform applications that can seamlessly transition from offline to online. The use case is that I'm working on an netless-enabled word processing app on an airplane. I get back to the office and connect to the network. If the web-app could detect the offline/online transition it would just sync up at that point. Without that ability, it won't. The "Work Offline" menu item doesn't factor into the case where the web-app needs to handle the connectivity dying.
(In reply to comment #6) > The use case is that I'm working on an netless-enabled word processing app on > an airplane. I get back to the office and connect to the network. If the > web-app could detect the offline/online transition it would just sync up at > that point. Without that ability, it won't. The "Work Offline" menu item > doesn't factor into the case where the web-app needs to handle the connectivity > dying. No, that's nonsensical -- we're going to get that notification after the network has gone away, so the app is already stranded. When the user selects "Work Offline", the app can take whatever actions it would take on receiving a "network lost" notification.
Comment 8•16 years ago
|
||
I was just looking at the OS X SystemConfiguration framework documentation re: network reachability [1] and realized that online/offline mode may actually need to be site-specific, rather than global across the whole browser session. For instance, it could be the case that the user has a wired connection to a LAN and is accessing one site through that in tab A, and is accessing google through a wireless internet connection in tab B; should the wireless connection go down, tab B should switch to offline mode, but tab A should stay in online mode. Based on what I've seen of the WhatWG specification, this doesn't seem to violate it in any way--just means that rather than the online/offline mode being browser-wide, it should be per-tab and always auto-detected, I assume? (I did some searching and noticed that this has basically been a known frailty since at least 2001, with bug 87717... Until this notion of browser-based vs. page-based online/offline state is resolved, though, it seems to me as though any efforts to auto-detect online/offline state for the whole browser will always end up frustrating some of our users.) [1] http://developer.apple.com/documentation/Networking/Reference/SysConfig/SCNetworkReachability/index.html
What Shaver said. When we find out we've lost connectivity, it's obviously too late to sync anything. And most of the time there is no way to find out about impending connectivity loss in advance --- not only are there no APIs, but it's simply impossible to predict that the user is going to enter a tunnel, or a router is going to go down, or prepaid Internet access is about to expire, or the user is going to yank the network cable, etc etc. So, applications have to be prepared to run offline without prior warning, which generally means they need to be continuously synced.
It's a known issue that connectivity is really per-server. However, making that part of the API would add a lot of complexity that would actually be very hard for applications to handle, e.g. if they make use of resources across multiple servers. We need to focus on making the common case of all-or-nothing connectivity work well before we go in that direction.
Reporter | ||
Comment 11•16 years ago
|
||
Ah, Shaver's right about that. However, here's the kicker: Because online/offline doesn't get signaled to the browser, the browser doesn't correctly know when to look in the application cache to get the offline when offline. Here's case in point. (1) On the Mac, go to http://starkravingfinkle.org/projects/offline/todo.html (2) Disconnect your internet. (3) Reload the page. Note that the page doesn't load -- you get a net failure message. (4) Go the the File menu and select "Work Offline" (5) Reload the page. It works! Grrr. Atul was able to reproduce this on a XP VM (host being OS X)
Comment 12•16 years ago
|
||
I should note that when I reproduced this on an XP VM, it wasn't the case that Windows XP thought a network cable was unplugged; I actually disabled wireless on my host OS X system, which would've rendered the VMWare NAT disfunctional. As a result, Windows XP probably didn't send any notifications that the network went down.
Reporter | ||
Comment 13•16 years ago
|
||
Here's a solution to the problem that shouldn't require any platform specific code: (1) Attempt to connect to a page. (2) At some point FF decides that the page cannot load and will display the "Can't Access Site" page. (3) Before displaying that page, check to see if the site exists in the application cache (i.e., the thing that would appear if "Work Offline" had been selected). (4) If it exists, show that instead of the "cannot access site" page. If it doesn't exist, show the "cannot access site" page. This method solves the global/local problem that Atul talked about here: https://bugzilla.mozilla.org/show_bug.cgi?id=426932#c8, and hopefully won't require any largely new chunk of code. It should just work, and the user will never have to learn what this mysterious, non-visible, and non-obvious "Work Offline" thing is or how to use it.
R(In reply to comment #11) > Ah, Shaver's right about that. However, here's the kicker: Because > online/offline doesn't get signaled to the browser, the browser doesn't > correctly know when to look in the application cache to get the offline when > offline. It does on Windows and Linux. As I said, there is a Mac-specific piece of work that needs to be done here. > Atul was able to reproduce this on a XP VM (host being OS X) (In reply to comment #12) > I should note that when I reproduced this on an XP VM, it wasn't the case that > Windows XP thought a network cable was unplugged; I actually disabled wireless > on my host OS X system, which would've rendered the VMWare NAT disfunctional. > As a result, Windows XP probably didn't send any notifications that the > network went down. Right. There is no easy way to detect on-the-fly that, while the local network is up, some link between the local network and the Internet (or the site you care about) has gone down. If you were using Windows on the base system and turned off wireless, or if you'd turned off networking in the VM, then that would have been detected by the browser and reported to the Web app. An easy small fix that would help would be for network error pages to offer a "Work Offline" button or link so that users can easily and discoverably enter offline mode if they have to. A bigger fix would be to support per-site offline mode and automatically enter it on network errors, but that needs considerable thought and careful design.
(In reply to comment #13) > Here's a solution to the problem that shouldn't require any platform specific > code: > > (1) Attempt to connect to a page. > (2) At some point FF decides that the page cannot load and will display the > "Can't Access Site" page. > (3) Before displaying that page, check to see if the site exists in the > application cache (i.e., the thing that would appear if "Work Offline" had been > selected). > (4) If it exists, show that instead of the "cannot access site" page. If it > doesn't exist, show the "cannot access site" page. > > This method solves the global/local problem that Atul talked about here: > https://bugzilla.mozilla.org/show_bug.cgi?id=426932#c8, and hopefully won't > require any largely new chunk of code. It should just work, and the user will > never have to learn what this mysterious, non-visible, and non-obvious "Work > Offline" thing is or how to use it. This is probably a good idea but it's harder than it looks. Right now online/offline mode is a global thing so that would have to be changed. Then you have to deal with situations where you have a page some of whose resources are "online" and some "offline". That could get confusing for Web developers. You also have to figure out when and how to reenter the "online" state.
Comment 16•16 years ago
|
||
(In reply to comment #14) > An easy small fix that would help would be for network error pages to offer a > "Work Offline" button or link so that users can easily and discoverably enter > offline mode if they have to. I'm a fan of this approach for the near future. Analogously, an actual button for "Switch to online mode" in the "Firefox is currently in offline mode and can't browse the Web"-style page--rather than the current static text saying "Place the browser in online mode and try again"--would be nice too.
Reporter | ||
Comment 17•16 years ago
|
||
> An easy small fix that would help would be for network error pages to offer a
> "Work Offline" button or link so that users can easily and discoverably enter
> offline mode if they have to.
That is at least better than what we have now, and is only a copy change. Especially if it is just a button they can click to try it out (as Atul says). If we go this route, we should as quickly as possible move to the bigger fix when time permits.
@Rob: How is it that you could have some resources online and offline at the same time?
(In reply to comment #16) > (In reply to comment #14) > > An easy small fix that would help would be for network error pages to offer a > > "Work Offline" button or link so that users can easily and discoverably enter > > offline mode if they have to. > > I'm a fan of this approach for the near future. Please file a new bug for that. You could probably fix it yourself, it's just a bit of chrome work. > Analogously, an actual button > for "Switch to online mode" in the "Firefox is currently in offline mode and > can't browse the Web"-style page--rather than the current static text saying > "Place the browser in online mode and try again"--would be nice too. Yeah. Actually, we could make that even better; when we know for sure that there is no network available, we should not tell the user to put the browser in online mode and try again, since that isn't going to work. So we should have a different message for that case. Please file a new bug for that and feel free to take a crack at it...
Comment 19•16 years ago
|
||
Sure thing, I've just created bug 435323 and bug 435325.
Updated•16 years ago
|
Whiteboard: [RC2?] → [RC2-]
Comment 20•16 years ago
|
||
Folks - I had mentioned this problem on bug 336359 comment 42 and have bugged both the Webkit and IE8 folks about this very issue on their platforms. I have not seen what I consider to be the correct behavior here in either Firefox 2.0 or 3.X on Mac or Windows (XP) or any Webkit build to date. I have seen it on IE8 beta 1, but only under Vista. Firstly, this page is either incorrect, or is misleading: http://developer.mozilla.org/en/docs/Online_and_offline_events It makes the statement (under the section regarding 'navigator.onLine'): "Firefox 2 updates this property when switching to/from the browser's Offline mode, and when losing/regaining network connectivity in Windows and Linux." and later: "Network status autodetection was implemented in Firefox 2." How can that be when this bug is true for Firefox 3.0? Or is this describing different behavior such that I'm misreading this statement? Second, the world I live in is a client-side state, AJAXified world. I expect that when the user loses network connectivity (i.e. either the network interface goes down or they choose 'Work Offline'), that the 'navigator.onLine' flag would dynamically change to false (without traversing a page - I don't do that in my world) and, in addition, now that we have these fancy online/offline events, that I'd get an offline event. Then I could prompt the user, via some DHTML-drawn GUI, and say 'hey, I just lost the network but I can save your data' and then do so to DOM storage, to the eventually-to-be-implemented SQL storage or heck even send it out as JSON-encoded data via a mailto: URL. I realize this bug was filed for Mac OS X (probably in relation to the comment from the document above), but I'm not seeing the behavior I thought I'd see in any of these environments (FF3.0RC2 running on Windows XP or Mac - didn't try Linux). I see roc's comment 14 above, but I can't get it to work. And yes, I'm also running XP on a virtualized environment (Parallels) on the Mac and I actually disable Parallel's network interface such that XP believes it has lost its network connection. But 'navigator.onLine' just keeps reporting 'true'. Anybody have any thoughts? Does this make any sense or am I way off base here? Can I help by writing testcases or something? Cheers, - Bill
(In reply to comment #20) > Firstly, this page is either incorrect, or is misleading: > > http://developer.mozilla.org/en/docs/Online_and_offline_events > > It makes the statement (under the section regarding 'navigator.onLine'): > > "Firefox 2 updates this property when switching to/from the browser's Offline > mode, and when losing/regaining network connectivity in Windows and Linux." > > and later: > > "Network status autodetection was implemented in Firefox 2." > > How can that be when this bug is true for Firefox 3.0? Or is this describing > different behavior such that I'm misreading this statement? Because this bug is specifically a Mac bug. > Second, the world I live in is a client-side state, AJAXified world. I expect > that when the user loses network connectivity (i.e. either the network > interface goes down or they choose 'Work Offline'), that the > 'navigator.onLine' > flag would dynamically change to false (without traversing a page - I don't do > that in my world) and, in addition, now that we have these fancy > online/offline > events, that I'd get an offline event. Then I could prompt the user, via some > DHTML-drawn GUI, and say 'hey, I just lost the network but I can save your > data' and then do so to DOM storage, to the eventually-to-be-implemented SQL > storage or heck even send it out as JSON-encoded data via a mailto: URL. That is how it should work. > I realize this bug was filed for Mac OS X (probably in relation to the comment > from the document above), but I'm not seeing the behavior I thought I'd see in > any of these environments (FF3.0RC2 running on Windows XP or Mac - didn't try > Linux). I see roc's comment 14 above, but I can't get it to work. And yes, I'm > also running XP on a virtualized environment (Parallels) on the Mac and I > actually disable Parallel's network interface such that XP believes it has > lost its network connection. But 'navigator.onLine' just keeps reporting > 'true'. You should file a bug specifically on the Windows XP issue. It should be working. There may be an issue with the way Parallels configures the network interfaces.
Comment 22•16 years ago
|
||
I am running natively on Windows XP without virtualization and navigator.onLine never changes state and the new online and offline events are only sent when I use the "Work offline" menu item. Losing wireless signal or disabling my network adaptor have no effect with Firefox 3.0.
Please file a new bug about that!
Assignee | ||
Updated•16 years ago
|
Flags: blocking1.9.1?
Comment 24•16 years ago
|
||
Wouldn't stop 1.9.1 for this, but wanted, P2. Feel free to argue.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Priority: -- → P2
Comment 25•16 years ago
|
||
Arguing :) I've spoken to Dave Camp about this, and I think it's a pretty important thing for us to get right on OSX as well as Windows. I know that we're going to be doing more load from the offline cache in the 3.1 timeframe, but the events seem important for web apps. (In reply to comment #22) > I am running natively on Windows XP without virtualization and navigator.onLine > never changes state and the new online and offline events are only sent when I > use the "Work offline" menu item. Losing wireless signal or disabling my > network adaptor have no effect with Firefox 3.0. Hm, I just had kbrosnan confirm that on Windows things work as expected (events are fired) with Firefox 3.0.1 and 3.1, so I'm not sure what's happening in this comment.
Flags: blocking1.9.1- → blocking1.9.1?
Comment 26•16 years ago
|
||
Folks - I'm the commenter for #20 above and I can confirm that Firefox 3.0.1 on Windows XP (emulated in VMWare Fusion for Mac) is properly signaling online/offline events and properly updating the navigator.onLine property, both when toggling the Work Offline menu item and when the networking interface is brought up and taken down However, Firefox 3.0.1 on Ubuntu Linux 8.04 Hardy Heron (emulated in Parallels for Mac) only signals the offline/online events and updates the navigator.onLine property when toggling the Work Offline menu item, not when bringing the network interface up and down :-(. Firefox 3.0.1 on Mac exhibits this same behavior :-(. As a developer of 'web apps' (i.e. heavy AJAX where I keep a lot of state in JS in the browser and I'd like to know when the network itself actually goes down), I would love to get these platforms operating properly like their Windows counterpart. So, I'm going to second Mike's opinion that we need to get this sorted out and working for these other platforms... please! :-). As I've done with other bugs, I'm offering a nice bottle of wine or case of beer for the person responsible for getting this bug to the FIXEd state :-) Cheers, - Bill
Comment 27•16 years ago
|
||
Ok, so now I'll add some more fuel to the fire :-). I complained to the Microsoft folks about the fact that, on IE8 beta 1, the onLine property updating and the events firing as the network connectivity changed only worked on Vista. I wanted it to work for XP as well. I just found out yesterday that they fixed that behavior for IE8 beta 2 such that those events and state changes now happen on XP as well. C'mon folks!! Please fix this for Linux and Mac! Now there's browser pride at stake!! :-). Cheers, - Bill P.S. My bottle of wine or case of fine beer offer from above still stands! :-)
We have had problems on Linux, for which the bug number eludes me, which boil down to "there is no reliable way to find out if the network is available or not". So you might end up needing to send beverages to folks on that side of the stack, or more likely the distributors making the decisions about what versions of NetworkManager to ship, and how authoritative NM's claims about network state should be. :-/
Comment 29•16 years ago
|
||
(In reply to comment #28) > We have had problems on Linux, for which the bug number eludes me, probably bug 424626 (dup ?)
Comment 30•16 years ago
|
||
@Mike - Thanks for the reply. It was what I'd feared - no reliable way to get that across distros (at least using NetworkManager). @Antonio - Yes, that is the correct bug number. Sigh... Ok, so that leaves us with Mac. Anyone? :-) Cheers, - Bill
Assignee | ||
Comment 31•16 years ago
|
||
This should work, but I need to verify that using 0.0.0.0 as the reachability address works on 10.4, and need to figure out if I'm getting the runloop the right way.
Comment 32•16 years ago
|
||
Can some explain why this is a blocker for 1.9.1? Re-nominating to make sure this is tracked and we all agree here.
Flags: blocking1.9.1+ → blocking1.9.1?
Comment 33•16 years ago
|
||
Besides comment #25, this bug puts a big hole in our offline event support. We have this support on Windows. We removed unreliable support on Linux because we can't depend on NetworkManager to help. If we can get reliable support for offline events on Mac, it would certainly help our offline webapp feature set.
Assignee | ||
Comment 34•16 years ago
|
||
Attachment #340419 -
Flags: review?
Dave, who did you intend to review that?
Assignee | ||
Updated•16 years ago
|
Attachment #340419 -
Flags: superreview?(roc)
Attachment #340419 -
Flags: review?(smichaud)
Attachment #340419 -
Flags: review?
Comment 36•16 years ago
|
||
Comment on attachment 340419 [details] [diff] [review] v1 + CFRetain(mCFRunLoop); Generally we prefix C calls into Apple's frameworks with "::", so "::CFRetain(mCFRunLoop)".
Comment on attachment 340419 [details] [diff] [review] v1 + PRBool mLinkUp; + PRBool mStatusKnown; PRPackedBool + // The network reachability API can reach 0.0.0.0 without + // requiring a connection, there is a network interface available. Should there be an "if" in that comment? Boy it'd be great to have some kind of nsCFPtr<>! But not in this bug. + reinterpret_cast<nsNetworkLinkService*>(info); This can be a static_cast Do we actually need to retain our own reference to mCFRunLoop? Seems like the mReachability object should be doing that itself.
Comment 38•16 years ago
|
||
I'm going to test this patch (on OS X 10.4.11 and 10.5.4). But here's an initial question (the code is from nsNetworkLinkService::SendEvent()): + if (mStatusKnown) + event = NS_NETWORK_LINK_DATA_UNKNOWN; + else + event = mLinkUp ? NS_NETWORK_LINK_DATA_UP + : NS_NETWORK_LINK_DATA_DOWN; Shouldn't the first line be "if (!mStatusKnown)"?
Assignee | ||
Comment 39•16 years ago
|
||
(In reply to comment #37) > Do we actually need to retain our own reference to mCFRunLoop? Seems like the > mReachability object should be doing that itself. We need to hold on to its value for UnscheduleRunLoop, but I suppose we don't need to actually retain it.
Comment 40•16 years ago
|
||
(In reply to comment #39) In my testing (using CFGetRetainCount()) I've found that SCNetworkReachabilityScheduleWithRunLoop() does retain its "runLoop" object (in fact more than once). But it's not documented to do so (in SCNetworkReachability.h). So it may be best to continue retaining (and later releasing) mCFRunLoop.
Comment 41•16 years ago
|
||
I'm about to post a v2 patch that incorporates most of the suggested changes, plus a couple of others (one of which was needed to make it compile). I tested it on OS X 10.4.11 and 10.5.5 and had no problems.
Comment 42•16 years ago
|
||
As I promised, here's a version of dcamp's patch that incorporates most of the suggested changes, plus a couple more. I tested this on OS X 10.4.11 and 10.5.5, using added NSLog statements to observe when (for example) nsNetworkLinkService::UpdateReachability() and nsNetworkLinkService::SendEvent() got called (and what they did once called). I tested on a machine with an Ethernet connection. So my tests consisted of disconnecting and reconnecting the ethernet cable. They worked as expected -- a few seconds after disconnecting or reconnecting the cable, I saw the expected messages. More complicated tests (say of wireless and dialup connections) are also needed -- but I can't do them myself. (By the way, I found that tne nsNetworkLink service is initialized before the AppShell service. But (as I expected) that doesn't seem to cause any trouble.)
Attachment #340419 -
Attachment is obsolete: true
Attachment #340637 -
Flags: superreview?(roc)
Attachment #340637 -
Flags: review?(joshmoz)
Attachment #340419 -
Flags: superreview?(roc)
Attachment #340419 -
Flags: review?(smichaud)
Comment 43•16 years ago
|
||
Dcamp: As far as I'm concerned, I've r+ed your patch (including the changes I made) :-)
Comment 44•16 years ago
|
||
I also tested starting up Minefield (and sometimes the machine itself) with the Ethernet cable disconnected. I got the expected results -- when called from nsNetworkLinkService::Init(), nsNetworkLinkService::UpdateReachability() set mLinkUp to PR_FALSE (reachable and needsConnection were both PR_TRUE). Reconnecting the cable caused nsNetworkLinkService::UpdateReachability() (when called again, on the "reachability change") to set mLinkUp to PR_TRUE (reachable was PR_TRUE and needsConnection was PR_FALSE). (Oops, just noticed that I forgot to turn mLinkUp and mStatusKnow into PRPackedBool flags.)
Attachment #340637 -
Flags: superreview?(roc) → superreview+
Attachment #340637 -
Flags: review?(joshmoz) → review+
Assignee | ||
Comment 45•16 years ago
|
||
Changed to PRPackedBool and landed as http://hg.mozilla.org/mozilla-central/rev/3ea2c46a9814 Please open specific bugs for problems with online/offline state on the various platforms.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 46•16 years ago
|
||
verified fixed using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre. I verified using https://bugzilla.mozilla.org/attachment.cgi?id=220609 with both wireless and ethernet connections here in the office.
Status: RESOLVED → VERIFIED
Comment 47•16 years ago
|
||
Is this a dupe of bug 336285, in which case I'm super happy?
Comment 48•16 years ago
|
||
David - I'm super happy too! I think this is a dupe of that bug, but someone else here with more knowledge than I of the issues should verify that and mark as DUP if that's the case. Dave Camp, you have my sincerest thanks. As per comment #27, please contact me should you wish to collect :-). Thank you again Dave! Cheers, - Bill
Comment 50•16 years ago
|
||
Glad 1.9.1 gets the fix, but not an appropriate change for 3.0.x security updates.
Flags: wanted1.9.0.x+ → wanted1.9.0.x-
Comment 51•15 years ago
|
||
This landed prior to 1.9.1 branching
Flags: blocking1.9.1? → blocking1.9.1+
Keywords: fixed1.9.1
Comment 52•13 years ago
|
||
In Firefox 7.0.1 on Mac OS 10.6.8 (at least) navigator.onLine returns false if File > Work Offline is selected -- but doesn't respond to turning off Airport (i.e. still returns true).
Comment 53•13 years ago
|
||
(In reply to comment #52) This sounds like a different bug -- possibly an Apple bug. Please test with FF 8.0.1 (the current version) and today's mozilla-central (trunk) nightly (ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/). If the problem persists, open a new bug on it. When you do, please provide detailed information, including precise steps-to-reproduce.
Comment 54•12 years ago
|
||
See https://bugzilla.mozilla.org/show_bug.cgi?id=654579#c9
Updated•5 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•