Neither XRE_START_OFFLINE nor -offline work any more

RESOLVED FIXED in Firefox 41

Status

()

Core
Networking
RESOLVED FIXED
3 years ago
3 years ago

People

(Reporter: neil@parkwaycc.co.uk, Assigned: valentin)

Tracking

({regression})

40 Branch
mozilla42
regression
Points:
---

Firefox Tracking Flags

(firefox40 wontfix, firefox41+ verified, firefox42 fixed, relnote-firefox 40+)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
It's no longer possible to start Thunderbird, SeaMonkey or Firefox offline. Neither the -offline startup switch nor the XRE_START_OFFLINE environment variable used by the Profile Manager work any more.
(Reporter)

Comment 1

3 years ago
(Thunderbird and SeaMonkey's offline.startup_state preference still seems to work.)

Comment 2

3 years ago
-offline is needed to facilitate debugging
(Assignee)

Comment 3

3 years ago
This is probably caused by either bug 1134596 or bug 654579 or most likely a combination of the two.
Does setting network.manage-offline-status to false fix the issue ? If so, we can just revert https://hg.mozilla.org/mozilla-central/rev/fc9297fa66aa and all should be well.
Flags: needinfo?(neil)
(Reporter)

Comment 4

3 years ago
(In reply to Valentin Gosu from comment #3)
> Does setting network.manage-offline-status to false fix the issue ?

Sorry, but that doesn't seem to make any difference.
Flags: needinfo?(neil)
(Assignee)

Updated

3 years ago
Assignee: nobody → valentin.gosu
(Assignee)

Comment 5

3 years ago
Created attachment 8631032 [details] [diff] [review]
Neither XRE_START_OFFLINE nor -offline work any more

I shouldn't have added this part. SetOffline(false) is first called from nsIOService::Init, which is enough. Optionally, XREMain::XRE_mainRun will also call SetOffline(true) if the -offline flag is passed. We don't call it for the do-profile-change notification as well.
Attachment #8631032 - Flags: review?(honzab.moz)
Comment on attachment 8631032 [details] [diff] [review]
Neither XRE_START_OFFLINE nor -offline work any more

Review of attachment 8631032 [details] [diff] [review]:
-----------------------------------------------------------------

Good! (untested)
Attachment #8631032 - Flags: review?(honzab.moz) → review+
(Reporter)

Comment 7

3 years ago
This works in Firefox but Thunderbird and SeaMonkey seem to expect network.manage-offline-status to be false, which was changed in all.js recently (previously it was only set in firefox.js). Please let me know whether this change is intentional so that Thunderbird and SeaMonkey can override it if necessary.
(Assignee)

Comment 8

3 years ago
(In reply to neil@parkwaycc.co.uk from comment #7)
> This works in Firefox but Thunderbird and SeaMonkey seem to expect
> network.manage-offline-status to be false, which was changed in all.js
> recently (previously it was only set in firefox.js). Please let me know
> whether this change is intentional so that Thunderbird and SeaMonkey can
> override it if necessary.

That change was intentional. We can flip it back if necessary, but overriding it is preferable.
(Reporter)

Comment 9

3 years ago
(In reply to Valentin Gosu from comment #8)
> (In reply to comment #7)
> > This works in Firefox but Thunderbird and SeaMonkey seem to expect
> > network.manage-offline-status to be false, which was changed in all.js
> > recently (previously it was only set in firefox.js). Please let me know
> > whether this change is intentional so that Thunderbird and SeaMonkey can
> > override it if necessary.
> 
> That change was intentional. We can flip it back if necessary, but
> overriding it is preferable.

Actually, perhaps the -offline startup switch should call SetManageOfflineStatus(false)?
(Reporter)

Comment 10

3 years ago
Forget that, it wouldn't work, because the preferences get loaded too late.
(Assignee)

Updated

3 years ago
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/48fd33776581
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox42: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla42
Duplicate of this bug: 1183992
Release Note Request (optional, but appreciated)
[Why is this notable]: IMHO major feature for people like me.
[Suggested wording]: Starting in Offline Mode doesn't work.
[Links (documentation, blog post, etc)]: -
status-firefox40: --- → affected
status-firefox41: --- → affected
relnote-firefox: --- → ?
Landing fix in 41.0a2, too?
Sorry, for reopening the bug!

I just guess that my question for FF 40 & 41 and the release notes was getting lost ...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 17

3 years ago
Comment on attachment 8631032 [details] [diff] [review]
Neither XRE_START_OFFLINE nor -offline work any more

Approval Request Comment
[Feature/regressing bug #]:
bug 1134596
[User impact if declined]:
Not able to start the browser in offline
[Describe test coverage new/current, TreeHerder]:
We don't have any automated tests for offline features. We rely on manual QA.
[Risks and why]:
Low risk. This has been on nightly for two weeks with no ill effects. 
[String/UUID change made/needed]:
None
Attachment #8631032 - Flags: approval-mozilla-beta?
Attachment #8631032 - Flags: approval-mozilla-aurora?
The patch has landed on m-c.  It means the bug is fixed.  To ask for an approval to branches you don't need to reopen a bug.


Personally I'm not a big fan to land this on Beta a week before merge to Release.  Changes to this code are sensitive.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Comment on attachment 8631032 [details] [diff] [review]
Neither XRE_START_OFFLINE nor -offline work any more

Dropping the request unless this is critical - which is not.
Attachment #8631032 - Flags: approval-mozilla-beta?
status-firefox40: affected → wontfix
Tracked for FF41.
tracking-firefox41: --- → +
Comment on attachment 8631032 [details] [diff] [review]
Neither XRE_START_OFFLINE nor -offline work any more

Offline mode is not working. Yikes! Let's uplift to Aurora soon.
Attachment #8631032 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Valentin, this is such a basic thing that we should be thinking about adding an automated test. Who should I discuss it with?
Flags: needinfo?(valentin.gosu)
Requesting QE team to verify this fix on nightly and Aurora when possible.
Flags: qe-verify+
(Assignee)

Comment 24

3 years ago
(In reply to Ritu Kothari (:ritu) from comment #22)
> Valentin, this is such a basic thing that we should be thinking about adding
> an automated test. Who should I discuss it with?

The problem with tests is that our frameworks usually expect connectivity to persist at all times (for logs and etc).
We probably need some help from the Automation team. Even basic support for online/offline tests would be great.
Flags: needinfo?(valentin.gosu)
Florin, just wondering, if this is already part of SV test plan. If not, can we add it? Thanks!
Flags: needinfo?(florin.mezei)
(In reply to Ritu Kothari (:ritu) from comment #25)
> Florin, just wondering, if this is already part of SV test plan. If not, can
> we add it? Thanks!

There was no plan to test this (most likely would have been picked up 1-2 weeks after 41 reached Beta, during the Firefox 41 Beta triage, where we review all fixes in Core, Platform, and Firefox for the new Beta, and decide what needs verification with higher priority). I'm keeping the needinfo so we have a look when time allows - likely next week due to higher priority work on Beta 40 and Windows 10.
Not fixed with Win7, 64bit and FF41.0a2, Build, 2015-07-29, 64bit, e10s.
I tested it a day to early?
status-firefox41: fixed → affected
Target Milestone: mozilla42 → mozilla41
(In reply to Tobias B. Besemer [:BesTo] from comment #28)
> Not fixed with Win7, 64bit and FF41.0a2, Build, 2015-07-29, 64bit, e10s.
> I tested it a day to early?

Yes I believe so. Can you please check with 07-30 build as this was checked into Aurora (FF41) channel 07-29 am PST. If it still does not work for you with 07-30 build of Aurora or later, please re-open.
status-firefox41: affected → fixed
Flags: needinfo?(Tobias.Besemer)
Target Milestone: mozilla41 → mozilla42
(In reply to Ritu Kothari (:ritu) from comment #29)
> Can you please check with 07-30 build as this was checked
> into Aurora (FF41) channel 07-29 am PST. If it still does not work for you
> with 07-30 build of Aurora or later, please re-open.

Tested with:
Win7, 64bit and FF41.0a2, Build, 2015-07-30, 64bit, e10s.
All works now fine!

Question: Why is this fix "Target Milestone: mozilla42", when it is already in mozilla41?
Flags: needinfo?(Tobias.Besemer)
Thanks Tobias. This was first fixed in Nightly (FF42) which is mozilla-central aka trunk. See comment 12. The target milestone typically reflects the trunk version i.e. FF42 in this case. FF41 status is reflected in flag status-firefox41. Hope that helps!

Updated

3 years ago
status-firefox41: fixed → verified
Added to the 40 release notes as a known issue with "Starting in offline mode does not work (1179779)" as wording.
relnote-firefox: ? → 40+
Removing the needinfo on me since this was verified in comment 30. Thanks Tobias!
Flags: needinfo?(florin.mezei)
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.