User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL) Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040902 Firefox/1.0 PR (NOT FINAL) In bug 255654 the File menu item for Offline support was disabled, since this feature will not be bug-free for version 1. Offline mode should not be available from the Profile Manager either. Reproducible: Always Steps to Reproduce: 1. Launch Firefox using firefox -P or firefox -ProfileManager Actual Results: Checkboxes for Offline Mode and Don't ask at startup are available Expected Results: Offline mode checkbox should be hidden

Does not block PR, the profile manager is considered advanced UI.

This bug is about removing it, because of PR. See bug 255654.

Just comment it out for now.

Comment on attachment 157731 [details] [diff] [review] Comment out offline mode option You cannot unconditially remove it, because it is required for Thunderbird.

And this bug does *not* block PR. Do not change the PR flag.

Does this work?

(In reply to comment #5) > And this bug does *not* block PR. Do not change the PR flag. Sorry, but I figured that releasing the PR with UI for a removed feature somewhat silly, especially if it's such a trivial change.

Comment on attachment 157734 [details] [diff] [review] Only for firefox You're getting closer, but I don't think you tested it: you need to also #ifdef the code at http://lxr.mozilla.org/aviarybranch/source/toolkit/profile/content/profileSelec tion.js#120 or else it will throw an exception

Comment on attachment 157737 [details] [diff] [review] Patch v3 - needs to be backed out on trunk a=asa for branch checkin.

Fixed, branch and trunk (should I have fixed this on the trunk? do we want offline on the trunk?)

Bug 255654 did not land on the trunk, and Asa specifically tells people to get a trunk build if they can't live without offline support: http://bugzilla.mozilla.org/show_bug.cgi?id=255654#c15 So this bug's patch should probably be backed out on the trunk.

Nick, that we had it in the past and I suggested people find it on the trunk doesn't mean I was suggesting that it was a trunk requirement.

dbaron, can you revert this one too? /be

Backed out of the aviary branch.

(Although as far as I can tell, the profile manager UI for offline mode doesn't do anything even with offline UI enabled again. But maybe I'm doing something wrong...)

Now that Firefox is back on the trunk, I noticed that the change was not reverted there. It would be nice to do this for consistency with 1.0.

Please do *not* land this on the trunk, it is an app-specific #ifdef.

I am proposing that the application specific ifdef be removed from the trunk. http://lxr.mozilla.org/seamonkey/source/toolkit/profile/content/profileSelection.js#120 http://lxr.mozilla.org/seamonkey/source/toolkit/profile/content/profileSelection.xul#81 I was checked into branch and trunk, but only reverted on the branch.

The Firefox 1.0 Profile Manager offers Work Offline. The trunk build does not currently. See comment 19.

Requesting 1.1 blocking, since this is a regression from 1.0, what with the app-specific code. Is profile management planned to be part of XULRunner, or be layered on top of it by apps as needed?

> Is profile management planned to be part of XULRunner, or be layered on top of > it by apps as needed? Profile management is a core function of XULRunner. (See http://wiki.mozilla.org/wiki/XUL:Xul_Runner#User_Profiles)

I have removed the #ifdefs.

Any reason the comments weren't removed? There's no reason to leave a reference to this bug there.

Sure there is... bugzilla references can be very important for understanding why the code has bizarre things like an offline switch in the profile manager.

(In reply to comment #26) > Sure there is... bugzilla references can be very important for understanding why > the code has bizarre things like an offline switch in the profile manager. Right, but this bug won't help explain that line all, it was just about removing (then restoring) it. It doesn't really matter. Verified per latest beast build. As mentioned in comment 16, it doesn't seem to have any affect, but that's something for another bug.