Closed Bug 857672 Opened 12 years ago Closed 12 years ago

Address Bar not working

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Version:
20 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
firefox20 + ?
firefox21 + verified
firefox22 --- unaffected
relnote-firefox --- -

People

(Reporter: tdowner, Assigned: Yoric)

References

Details

(Keywords: common-issue+, Whiteboard: [testcase: see comment 50])

We've started to see reports coming into SUMO around the Address Bar not working after an update to Firefox 20. https://support.mozilla.org/en-US/questions/955140 https://support.mozilla.org/en-US/questions/955232 https://support.mozilla.org/en-US/questions/955247 It seems to be because the users are using Roaming Profiles (multiples references to that) in a Windows Server Environment. We aren't 100% sure of what's going on here yet though.
I don't think QA has access to the necessary environment to debug this issue (ie. Windows Server infrastructure with roaming profiles). Maybe we could reach out to our Enterprise tester mailing list to get more insight on this issue?
Component: General → Location Bar
Gavin - I'll send an email to the enterprise mailing list asking for help testing around this, hopefully you (or someone else who you think can be engineering point on this bug) can field input if more comes in to help us get ahead on the investigation here and determine if this worth tracking.
Assignee: nobody → gavin.sharp
at first glance looks similar to the issues we have with SQLite on network shares (bug 719952). I know that roaming profiles work differently, but I still suspect the problem is with SQLite access to the file. In version 20 we took SQLite 3.7.15.1 version, while version 19 was on 3.7.14.1. First thing to do is to verify the changes in that SQLite version and if they may have caused problems with the db access that were maybe ignored before. Off-hand I cannot think of other changes to Places that may cause problems in very specific situations like roaming profiles.
As I mentioned on dev-firefox, OS.File didn't work with UNC paths until bug 846848 landed in 22. I have no clue if anything in address bar land uses OS.File.
https://support.mozilla.org/en-US/questions/955140#answer-423149 Some of the users reporting this are sharing thoughts there. It may be related to folder redirection more than the roaming profiles idea. Most roaming profiles users also use folder redirection to keep centralized versions of files on the server. One user reported it not being an issue for those of his users that didn't use folder redirection but it was for those that did. And he doesn't use roaming profiles.
(In reply to Gregory Szorc [:gps] from comment #5) > As I mentioned on dev-firefox, OS.File didn't work with UNC paths until bug > 846848 landed in 22. I have no clue if anything in address bar land uses > OS.File. Not the address bar, but may be related to some service initialized by OS.File on first address-bar use (search service?). If Firefox 22 has no problems in the same situation is more likely OS.File since SQLite didn't have deep changes in vfs on the latest version.
So, I guess we need someone to setup a roaming profile env where the bug can be reproduced with Firefox 20, and try reproducing it with Firefox 22 (on a testing profile), or on a custom firefox 20 build with the OS.File fix.
I'm experiencing the issue firsthand... how do I get FF22 to test?
Same issue here using Roaming Profiles and Folder Redirection on many Win7 workstations with Windows Server 2008 R2 servers.
(In reply to brentpirolli from comment #9) > I'm experiencing the issue firsthand... how do I get FF22 to test? you may just try with a Nightly, since we merged just a couple days ago. Just be sure to create a new test profile, using the same profile across different versions may break it. http://nightly.mozilla.org/
Nightly = 23.0a1 Beta = 20.b6 Aurora = 21.a2 ... no 22. :-( I'll give 23 a shot and see what happens.
testing with 23 (Nightly) should be fine.
Issue is NOT present in Nightly (23.0a1)
Nightly 23.0a1 works here too ... at least on one account/machine.
OK, even if we upgraded to SQLite 3.7.16 in Firefox 22, just by looking at the changelog for the 2 versions it's very unlikely to have changed things. I can 90% exclude it as a cause... Gregory, may you create a trybuild of Firefox 20 with the fix for OS.File to test?
Flags: needinfo?(gps)
Additional testing that could be useful, for people seeing this: 1) Open the Error Console (Tools->Web Developer->Error Console, or Firefox Menu->Web Developer->Error Console), select the "Errors" tab, and take note of any errors that are listed there. 2) Open a new Firefox window. Take note of whether any new errors appear in the console. 3) Reproduce the bug (press enter in the URL bar), and again take note of whether any new errors appear in the console. Pasting any errors you see from those steps here in the bug would be helpful.
Upon initial install and open of 20: Timestamp: 4/3/2013 4:51:05 PM Error: [Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]" nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)" location: "JS frame :: resource://gre/modules/XPCOMUtils.jsm :: XPCU_serviceLambda :: line 202" data: no] Source File: chrome://browser/content/tabbrowser.xml Line: 404 Timestamp: 4/3/2013 4:51:04 PM Error: NS_ERROR_XPC_GS_RETURNED_FAILURE: Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService] Source File: chrome://browser/content/search/search.xml Line: 140 Timestamp: 4/3/2013 4:51:04 PM Error: Error: Module Path cannot handle UNC-formatted paths yet: \\main\users\BrentP\Application Data\Mozilla\Firefox\Profiles\lv08adt2.default Source File: resource://gre/modules/osfile/ospath_win_back.jsm Line: 256 Timestamp: 4/3/2013 4:51:03 PM Error: [Exception... "'Error: Module Path cannot handle UNC-formatted paths yet: \\main\users\BrentP\Application Data\Mozilla\Firefox\Profiles\lv08adt2.default' when calling method: [nsIObserver::observe]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] ---- Upon opening a new window: Timestamp: 4/3/2013 4:53:46 PM Error: NS_ERROR_XPC_GS_RETURNED_FAILURE: Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService] Source File: chrome://browser/content/search/search.xml Line: 140 Timestamp: 4/3/2013 4:53:46 PM Error: AboutHomeUtils.defaultSearchEngine is undefined Source File: chrome://browser/content/browser.js Line: 9820 Timestamp: 4/3/2013 4:53:48 PM Error: _SessionFile is not defined Source File: resource:///modules/sessionstore/SessionStore.jsm Line: 3748
Flags: needinfo?(gps)
Here's the output from error console: Timestamp: 4/3/2013 4:49:09 PM Error: [Exception... "'Error: Module Path cannot handle UNC-formatted paths yet: \\pdc01\users\bgates\Application Data\Mozilla\Firefox\Profiles\eqfi5uq5.default' when calling method: [nsIObserver::observe]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no] Timestamp: 4/3/2013 4:49:10 PM Error: Error: Module Path cannot handle UNC-formatted paths yet: \\pdc01\users\bgates\Application Data\Mozilla\Firefox\Profiles\eqfi5uq5.default Source File: resource://gre/modules/osfile/ospath_win_back.jsm Line: 256
Oh, and pressing enter on a typed in URL gives no new errors, but pressing the arrow gives: Timestamp: 4/3/2013 4:55:39 PM Error: TypeError: Services.search is undefined Source File: chrome://browser/content/browser.js Line: 9470
Depends on: 846848
Timestamp: 4/3/2013 3:47:19 PM Error: NS_ERROR_XPC_GS_RETURNED_FAILURE: Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService] Source File: chrome://browser/content/search/search.xml Line: 140 No new info. Just verifying similar errors here: Timestamp: 4/3/2013 3:47:19 PM Error: AboutHomeUtils.defaultSearchEngine is undefined Source File: chrome://browser/content/browser.js Line: 9820 Timestamp: 4/3/2013 3:47:21 PM Error: [Exception... "'Error: Module Path cannot handle UNC-formatted paths yet: \\ANESFS1\Home$\rpsteiner\settings\Application Data\Mozilla\Firefox\Profiles\ml93mwfn.default' when calling method: [nsIObserver::observe]" nsresult: "0x8057001c (NS_ERROR_XPC_JS_THREW_JS_OBJECT)" location: "native frame :: <unknown filename> :: <TOP_LEVEL> :: line 0" data: no]
Great, thanks! So it seems pretty clear that there is just a lot of general bustedness involved (several exceptions in chrome), and likely the most visible manifestation of that bustedness is the URL bar not working. It also confirms that UNC path support in OS.File is the issue: Error: Error: Module Path cannot handle UNC-formatted paths yet: \\main\users\BrentP\Application Data\Mozilla\Firefox\Profiles\lv08adt2.default Source File: resource://gre/modules/osfile/ospath_win_back.jsm
Assignee: gavin.sharp → dteller
Is it too early to question what kind of testing/QA we have around remote profiles?
(In reply to Gregory Szorc [:gps] from comment #23) > Is it too early to question what kind of testing/QA we have around remote > profiles? See comment 1, we are not set up to be able to test roaming profiles. As I understand it this would require somehow mimicking a Windows client-server environment. I wouldn't even know where to begin.
Well, if we plan on keeping enterprise users, we should defo get this setup. If we can't provide what they need, what's the point in trying? It shouldn't be too hard to setup something simple, and in fact MS have step by step guides on it.
(In reply to Thomas [:Tad] from comment #25) > Well, if we plan on keeping enterprise users, we should defo get this setup. > If we can't provide what they need, what's the point in trying? > > It shouldn't be too hard to setup something simple, and in fact MS have step > by step guides on it. That's a fair enough point. I'm going to take that discussion offline with my peers and will not be discussing it further in this bug.
I don't see this being a chemspill driver, unless it affects a significant percentage of users so we'll ensure the fix is uplifted to beta (ff21) and not track for 20.
status-firefox20: --- → affected
status-firefox21: --- → affected
status-firefox22: --- → unaffected
tracking-firefox20: ? → -
tracking-firefox21: --- → +
https://mxr.mozilla.org/mozilla-release/search?string=osfile.jsm&tree=mozilla-release reveals other users of OS.File in 20. FHR is not enabled until 21, so not an issue. However, it looks like session manager and the new download panel import OS.File. I haven't looked to see how they might be impacted.
Obviously I don't know how many people this affects offhand, but I'm not sure you guys are grasping the full scale of this bug. This is a total blocking issue for ANY enterprise environment that uses folder redirection. It renders the program 100% unusable. Just about every windows server environment of relatively medium-large scale uses folder redirection (and a large number use roaming profiles too, but that's not the ultimate issue here). Folder Redirection allows all user files to be backed up on servers instead of on individual machines where they are subject to loss if a drive fails, so it's a pretty common practice. My guess... hundreds of thousands, if not millions of users worldwide are affected by this. Like Thomas said, this is a MAJOR deal for enterprise users and you have over a thousand represented on this thread alone between rpsteiner and myself. If you wait until FF21 to resolve this, you are forcing a large percentage of your userbase to alternative browsers over the coming weeks... especially with auto-update pushing them to 20 without admin interaction. It's your call... but if it were mine, I'd highly recommend you make this a priority update for 20.01 ASAP. I've already had to email my userbase and explain how to disable auto-updates. :-(
I'm wondering why some enterprise admins opt to use Firefox mainline when we created a more stable branch just for them (Firefox ESR). I'm not downplaying the severity of this issue, in fact I think we should fix this as soon as we can, but any enterprises on Firefox 17esr would be unaffected by this bug.
This is a 100% serious issue. Anthony is aware of this. He has recently contacted me about having an in-house server setup running Windows and a few clients. While this will be done as soon as possible, there will be many considerations that the Mozilla IT team will need to consider, so please be patient. For now, I'd recommend that you downgrade back to 17ESR for now. We release these editions for long term support, so support will continue for the servers running this version of Firefox. I fail to mention that I've noticed this issue on my personal PC at home. Not sure of my profile type, but never have I installed a windows server, so I'd assume my profile is local. This was the nightly development stream. I found it to be an issue after hibernating my computer, getting a corrupt hyberfile then booting back up. Never filed a bug, because I have never had time to do so. Please don't be angry at Mozilla. We have provided enterprise releases for the last couple of years which are known to have zarro bugs. Do be patient while this is resolved. No, I'm not on QA. No, I'm not from release engineering. I volunteer in Mozilla IT team and the support. I was referred to this bug by someone on the support IRC chat.
(In reply to :Gavin Sharp (use gavin@gavinsharp.com for email) from comment #22) > Great, thanks! > > So it seems pretty clear that there is just a lot of general bustedness > involved (several exceptions in chrome), and likely the most visible > manifestation of that bustedness is the URL bar not working. It also > confirms that UNC path support in OS.File is the issue: > > Error: Error: Module Path cannot handle UNC-formatted paths yet: > \\main\users\BrentP\Application > Data\Mozilla\Firefox\Profiles\lv08adt2.default > Source File: resource://gre/modules/osfile/ospath_win_back.jsm Gavin, I see that you have assigned that bug to me, but I don't know what you expect me to do, besides perhaps ensuring that the patch of bug 846848 can be uplifted.
Flags: needinfo?(gavin.sharp)
(In reply to David Rajchenbach Teller [:Yoric] from comment #32) > besides perhaps ensuring that the patch of bug 846848 > can be uplifted. I think the ideas was exactly that one, prepare uplift patch and ask for aurora/beta approval. It was likely assigned to you cause you are assignee of bug 846848.
(In reply to brentpirolli from comment #29) > Obviously I don't know how many people this affects offhand, but I'm not > sure you guys are grasping the full scale of this bug. Don't worry, we are aware of it. The fix is undergoing testing right now.
Flags: needinfo?(gavin.sharp)
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #30) > I'm wondering why some enterprise admins opt to use Firefox mainline when we > created a more stable branch just for them (Firefox ESR). I'm not > downplaying the severity of this issue, in fact I think we should fix this > as soon as we can, but any enterprises on Firefox 17esr would be unaffected > by this bug. Honestly many enterprise environments don't regulate FF installs. They are installed by users individually who don't like corporate restrictions on slow IE rollouts. Many large corporations such as Proctor and Gamble or Owens Illinois, etc... are still on IE 6 or 8. The larger the roll-out, the slower it seems to go as they have to test browsers with a ton of internal sites and such. Users are frustrated with the lack of features or security and they self-install FF like a home user, so they know nothing of the ESR options. Heck, until this issue, as an IT Admin, I didn't know ESR existed! You guys live in this FF world so it's second nature to you, but the industry as I've seen it doesn't share this as common knowledge. (In reply to David Rajchenbach Teller [:Yoric] from comment #35) > Don't worry, we are aware of it. The fix is undergoing testing right now. Great! Just hoping it's not going to be released 6 weeks from now in 21. By then this issue will only have grown immensely in the corporate world. (In reply to Thomas [:Tad] from comment #31) > Please don't be angry at Mozilla. We have provided enterprise releases for > the last couple of years which are known to have zarro bugs. Not angry. Bugs happen. Just want to be sure it's addressed as quickly as possible to mitigate client losses/frustration. ;-) Thanks for all you are doing guys. I'm sure you'll handle it as responsibly as possible. Let me know if you want any help testing a fix in our environment or if you need any additional info.
FYI, bug report 857869 is a duplicate too.
(In reply to brentpirolli from comment #36) > Heck, until this issue, as an IT Admin, I didn't know ESR existed! http://www.mozilla.org/en-US/firefox/organizations/
Thanks for the reference to the ESR version, but I will confirm that as Director of IT for our organization, I was unaware of the existence of the ESR version until today. We are in the process of moving to it now on our Virtual Desktop Profiles. During the big Java security issue a few weeks back, Mozilla sent out a big blast informing users. I suggest a similar effort to address this bug. Regardless of how Mozilla thinks they have spread the word on ESR, I would bet a paycheck that a large number of enterprises are unaware of its existence.
The ESR version is somewhat irrelevant here and pointing to it is misleading, as this bug affects users that installed Firefox on their own, as explained in comment 36. We don't expect these people to use the ESR version.
(In reply to Dão Gottwald [:dao] from comment #41) > The ESR version is somewhat irrelevant here and pointing to it is > misleading, as this bug affects users that installed Firefox on their own, > as explained in comment 36. We don't expect these people to use the ESR > version. I respectfully disagree if you're saying that the ONLY people affected are those who installed Firefox themselves. My point is that our IT department (and I believe I am far from alone) installed Firefox Standard on our Enterprise, not knowing an enterprise version existed. I agree that the existence of an Enterprise version won't help those who continue to need (or use) the standard version. But knowing the enterprise version exists and is not affected by this problem does give those like us an alternative to waiting for a v.20 fix or v.21 to be released.
(In reply to Hal Bullock from comment #42) > (In reply to Dão Gottwald [:dao] from comment #41) > > The ESR version is somewhat irrelevant here and pointing to it is > > misleading, as this bug affects users that installed Firefox on their own, > > as explained in comment 36. We don't expect these people to use the ESR > > version. > > I respectfully disagree if you're saying that the ONLY people affected are > those who installed Firefox themselves. That's not what I said. This discussion is starting to derail this bug. Let's please stop it.
(In reply to Dão Gottwald [:dao] from comment #43) > That's not what I said. This discussion is starting to derail this bug. > Let's please stop it. Agreed, my apologies for derailing this bug a bit. I'll continue this discussion offline with the Release Management team.
(In reply to Thomas [:Tad] from comment #25) > Well, if we plan on keeping enterprise users, we should defo get this setup. > If we can't provide what they need, what's the point in trying? > > It shouldn't be too hard to setup something simple, and in fact MS have step > by step guides on it. First, there is a question that needs to be addresses that apparently hasn't been yet... There is a huge difference between: a) Roaming Profiles b) Redirected Folders (in this case specifically including %AppData%) whether in combo with Roaming Profiles or not, and c) Storing a profile remotely via a UNC path So, first thing that needs to happen is to define precisely which of the 3 different scenarios above are affected. As one who uses only simple Roaming Profiles (had too many issues with Redirected Folders), I have *not* seen any issues at all, with either XP Pro or Win 7 Pro.
(In reply to Charles from comment #45) > a) Roaming Profiles > b) Redirected Folders (in this case specifically including %AppData%) > whether > in combo with Roaming Profiles or not, and > c) Storing a profile remotely via a UNC path > > So, first thing that needs to happen is to define precisely which of the 3 > different scenarios above are affected. Firefox 20 breaks c), and given the data we have so far that's likely the only issue. We've confirmed that's the problem, and have a fix ready for Firefox 21 (and potentially, a Firefox 20.0.1).
I can confirm that a patch is on it's way after speaking with the dev who wrote the code which breaks this function. Please be patient with this. We don't expect things such as this to happen because we don't have the ability to test in similar environments to yours. We are working on setting a test system up in one of our offices, but this will be a strenuous activity for our Linux based IT team. It'll be done, though. Thanks for reporting this so fast. You could be saving hundreds of users from losing firefox, providing that the patch comes soon.
Status: NEW → ASSIGNED
(In reply to Thomas [:Tad] from comment #48) > Please be patient with this. We don't expect things such as this to happen > because we don't have the ability to test in similar environments to yours. > We are working on setting a test system up in one of our offices, but this > will be a strenuous activity for our Linux based IT team. It'll be done, > though. Well, you only need two Windows PCs for this particular issue (no server or domain required). Of course if you want to be able to test full blown roaming profiles and/or redirected folders, that will require a server, although you could use Samba4 - maybe even just use the free SOGo appliance?
Gavin gave me a test case which reproduces this bug quite trivially: 1. On a Windows PC (ComputerA), create a "share" folder at C:\ 2. Share this folder and give Everyone read/write access (do not map to a network drive) 3. On another Windows PC (ComputerB) start Firefox 20 with the profile manager 4. Create a new profile at \\ComputerA\share and start Firefox 5. Try to navigate to www.google.com Result: No navigation happens, errors in error console. Thank you so much, Gavin. At least we'll be able to verify when this is fixed now.
Whiteboard: [testcase: see comment 50]
Good Morning, I am running an enterprise network with about 650 clients. All of them are Windows 7 Service Pack 1 and all of our Servers are Windows Server 2008 R2 Professional Service Pack 1. We use various combinations of folder redirection, roaming profiles and unc-path storage. This Bug can be reproduced in all combinations we are using - not a single client is working correctly right now. -roaming + folder redirection -folder redirection without roaming -roaming without folder redirection -simple unc stored profiles At first I thought it had something to do with the depth of path/filename, but I confirmed this is not the case. In our test lab we had the profiles stored in \\server1\share1\profile1. My next guess where the NTFS ACLs / Permissions, but those were ruled out, too. Next we tried to store the profiles on a Windows 2003 Server, Windows 2000 Server, Samba Server, QNAP NAS with Samba/SMB implemented... nothing changed... I hope I was able to help a little bit. P.S. What I don´t understand is the opinion of some users / developers around here... My network is run by our government and we are subject to rules, guidelines, orders and stuff like that. Yesterday we were ordered to upgrade to Firefox 20 by a superior Organization Unit and so we did it. I have about 20 fellow Admins in Other Cities, that are facing the exact same Problem with their Clients right now. The whole number of clients affected by the bug in our organization is about 8240 clients ( 10:00 AM - MEST ). There is NO question at all, if we could use ESR Releases because we are ordered to "NOT USE THEM". So please don´t always take the "HEY ADMINS USE ESR - Joker" out of the pocket.
As stated above, this is under repair. Comments made about the esr release were directed at people in control over what happens. Yoric, is there an eta on the patch? We seem to be losing a lot of hearts from this bug.
Flags: needinfo?(dteller)
The patch itself is ready. Waiting for QA greenlight.
Flags: needinfo?(dteller)
Awesome Yoric. Hopefully QA approves it, and fast. This bug is imitating the behavior of flu.
Am I right, that the addressbar is tightly connected to the search and this is why the addressbar does not work if there is no search engine configured? Is there somewhere a link to the patch(descritption)? Just to get more understanding to the problem. I am more or less only a "User", not a developer, but actually I can't understand, why software in the year 2013 can't handle UNC pathes. Maybe we are in luck that no news-reporter has any idea what a UNC-path is :-)
Will this patch be included in a chemspill release? I saw various reports about this issue on Firefox forums.
I hope so. This is a widespread issue and IMO warrants a chemspill release, so please re-flag for tracking-firefox20? (or + right away). Of course, this needs some testing (which means it won't reach Release for another few days), but this bug should stay on the radar vor v20.
relnote-firefox: --- → ?
(In reply to David Rajchenbach Teller [:Yoric] from comment #55) > The patch itself is ready. Waiting for QA greenlight. At the time of posting this comment QA had already tested and verified the fix for bug 846848 works in Firefox Aurora 22. I have now also tested and verified the fix applied to the Firefox 20 try-server build you generated this morning. I think we are just waiting on Release Management's branch uplift approval at this point.
The plan of record is to release a Firefox 20.0.1 next week that includes Yoric's fix for this issue.
tracking-firefox20: - → +
I see that it's going to be in FF21 for sure. Any word on the 20.0.1 chemspill?
(In reply to brentpirolli from comment #64) > I see that it's going to be in FF21 for sure. Any word on the 20.0.1 > chemspill? See comment 61 -- we will be putting the fix into 21b2 early this week to get some pre-release feedback. If no further issues are discovered in Beta we will put it into a 20.0.1 later in the week.
Keywords: common-issue+
Verified fixed FF 21b2 in bug 846848
FF 21b2 20130408165307 works here. Let us know as soon as a 20.0.1 test version is available.
Marking this bug status-firefox21:verified based on comment 66.
status-firefox21: affected → verified
Verified fixed FF 20.0.1 in bug 846848
status-firefox20: affected → verified
FF 20.0.1 OK in my environment.
Hi, we've got the same problems, with windows 2003 and Terminal, our users are about to kill us and I can't find where to download FF 20.0.1, can you pls provide a link. thanks!
We've deployed Firefox to all of our Citrix XenApp installs over the past two years. I've had to remove it from 4 of them because of this issue and replace it with Chrome. I'm trying to keep the rest calm while we wait for this fix, but anything that can be done to hasten its release would be greatly appreciated by me and my clients!
Tomorrow at the latest FF 20.0.1 will be officially available on www.firefox.com. Meantime, you can find the build at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/20.0.1-candidates/build1/
thx
Same here - our numbers with the "bugged" version have grown over the last few days... We are running over 9200 clients - all affected by the bug. We have redirected/reset the default browsers to Chrome, Opera and IE ( given on what other browsers are installed on the clients ). Some applications aren´t running, some not as smooth as usual, some are crashing on the other browsers, all bookmarks of the users are gone ( stored in FF ) and they do not have their normal addons like dictionary, adblock plus... Please push out the fix as soon as you can, my users are hammering my mailbox and phone and my superiors are thinking of ways to completely get rid of Firefox. I am using FF since the early alphas/nightlies of Firebird, there were many Bugs over the time - but none of them rendered FF completely unusable to all of my users. My Firefox 1.0 T-Shirts stay where the are for the moment :-) I am not risking being stoned while crossing the floor to have my lunch break :-) Thanks for the good work over all those years - and thanks for fixing everything - but please hurry ! Greetings
Sorry :-) Yo were faster than me :-) Great News - Thanks a lot !
Sounds like you need to be using the ESR version - that is what it is for, and that is why Mozilla provided the ESR in the first place. If you are not going to use it, and you are not going to take the time to properly test new versions of the stable release if you choose to use it, then your users and bosses are absolutely correct to blame YOU for this problem. Also, why didn't you just roll the release back to 19? Easy to do, especially on a Terminal Server, no? Sheesh... (In reply to enz-coast from comment #76) > Same here - our numbers with the "bugged" version have grown over the last > few days... We are running over 9200 clients - all affected by the bug. We > have redirected/reset the default browsers to Chrome, Opera and IE ( given > on what other browsers are installed on the clients ). Some applications > aren´t running, some not as smooth as usual, some are crashing on the other > browsers, all bookmarks of the users are gone ( stored in FF ) and they do > not have their normal addons like dictionary, adblock plus... > > Please push out the fix as soon as you can, my users are hammering my > mailbox and phone and my superiors are thinking of ways to completely get > rid of Firefox. I am using FF since the early alphas/nightlies of Firebird, > there were many Bugs over the time - but none of them rendered FF completely > unusable to all of my users.
We are using no terminal servers... in comment #53 you can read my initial posting and you can read why I / we do not / can not use ESR. But now the waiting time is over and we´ve begun to test and to deploy the newest Version. Fix is working as intended in 20.0.1 -We´ve just deployed it to the first wave of my own 650 Clients -Positive results are coming in from other departments as we speak... -If there are no complications till tomorrow my site-admins will deploy 20.0.1 to the rest of the 9200 over the weekend. Thank you very much, time to get my FF T-Shirt out of the closet :-) Keep up the good work ! Respect - Bye
Sorry again about that bug, but glad to have real-world confirmation – and glad that you can wear your FF T-Shirt again :)
(In reply to enz-coast from comment #79) > We are using no terminal servers... I know, sorry, my comment was in general - many commenters were from people who were using TS. > in comment #53 you can read my initial posting and you can read why > I / we do not / can not use ESR. So, use this as a perfect example of why you should either be using the ESR, or people shouldn't freak out at the occasional minor breakage. Also... you mentioned that you had the problem on ordinary roaming profiles? As far as I can tell, this bug did not affect simple roaming profiles, it only kicked in when UNC network paths were in play (which they are NOT with simple roaming profiles). I know we use roaming profiles here, and have had no issues on 20+ workstations with version 20. > But now the waiting time is over and we´ve begun to test and to deploy > the newest Version. Yes, about a week from bug report to fix issued, so not too shabby...
Please don't let this turn into an argument between you. Mozilla made a mistake, and are sorry about this. We can't do anything except release this patch. If you would like to discuss the needs of ESR, or why you don't you it, please use our enterprise list.
Firefox 20.0.1 for windows is released, and this was noted in https://www.mozilla.org/en-US/firefox/20.0.1/releasenotes/ (pointing to bug 846848).
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
relnote-firefox: ? → -
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
status-firefox20: verified → ?
Flags: needinfo?
Flags: in-testsuite?
Flags: in-qa-testsuite?
Flags: in-moztrap?
We're using DFS name space and folder redirection for app data User profiles are local, but due to the folder redirection we were having the same problem with Firefox 20.0.0 Completely unusable. I have installed and tested 20.0.1 and it now has some limited functionality Although it can now open a web page, there are long delays in trying to open Firefox We are now receiving errors " Windows - Delayed Write Failed : Windows was unable to save all the data for the file \Device\WinDfs\Root\******.***\***\userappdata$\ffoxtest\Mozilla\Firefox\Profiles\1nc1d3r.default\cookies.sqlite-wal. The data has been lost. This error may be caused by a failure of your computer hardware or network connection. Please try to save this file elsewhere. " Any support would be appriciated
Flags: needinfo?
(In reply to cdouglas@independent.ie from comment #84) > Any support would be appriciated Might you file a new bug exposing this new issue, please. Just post the bug number here, thanks.
Flags: needinfo?(cdouglas)
(In reply to cdouglas@independent.ie from comment #84) > We're using DFS name space and folder redirection for app data > User profiles are local, but due to the folder redirection we were having > the same problem with Firefox 20.0.0 > Completely unusable. > > I have installed and tested 20.0.1 and it now has some limited functionality > Although it can now open a web page, there are long delays in trying to open > Firefox > We are now receiving errors > " > Windows - Delayed Write Failed : Windows was unable to save all the data for > the file > \Device\WinDfs\Root\******. > ***\***\userappdata$\ffoxtest\Mozilla\Firefox\Profiles\1nc1d3r. > default\cookies.sqlite-wal. The data has been lost. This error may be caused > by a failure of your computer hardware or network connection. Please try to > save this file elsewhere. > " > > Any support would be appriciated I'm almost sure that this is a completely independent error. You should file a new bug.
Created a new bug Bug 864715 - Windows Write delay, Folder redirection
Flags: needinfo?(cdouglas)
I'm not sure if this can have Mozmill (or other framework?) coverage given STR from comment #50? Henrik, what do you think?
Flags: needinfo?(hskupin)
Well, it's a bug with a huge amount of comments. What would be the testing scenario here exactly? If someone could tell me that, I would appreciate it!
Flags: needinfo?(hskupin)
(In reply to Henrik Skupin (:whimboo) from comment #89) > Well, it's a bug with a huge amount of comments. What would be the testing > scenario here exactly? If someone could tell me that, I would appreciate it! As Mihaela said, comment 50 has STR.
Ups, sorry. You are right. So in general something like that should be possible in Mozmill, but we would have to make some enhancements first in regards of the profile location. So not sure when Mozmill would be ready for that. In-tree testsuites do not allow network access, so no way of getting it implemented there. I would suggest to have a moztrap test for this and other UNC related issues. We can then later decide what to do in regards of automation.
(In reply to Henrik Skupin (:whimboo) from comment #91) > We can then later decide what to do in regards of automation. The address bar is a "core" feature and I'd like to have this covered in automation sooner rather than later if at all possible. Is this a question of resources? If so, maybe that's something Mihaela could take ownership over. In the meantime, I agree we should have a Moztrap regression test covering this.
(In reply to Henrik Skupin (:whimboo) from comment #91) > I would suggest to have a moztrap test for this and > other UNC related issues. The Moztrap test for this is https://moztrap.mozilla.org/manage/cases/?filter-id=7514
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #92) > The address bar is a "core" feature and I'd like to have this covered in > automation sooner rather than later if at all possible. In case of our Mozmill tests this would include OS level interaction, which we don't support yet. I don't see at the moment when we could tackle that. > Is this a question of resources? If so, maybe that's something Mihaela could > take ownership over. In the meantime, I agree we should have a Moztrap > regression test covering this. I would wait until we moved to Marionette as backend engine. I don't want that necessary work like this gets obsolete in the next two quarters. We should revisit then.
(In reply to Henrik Skupin (:whimboo) from comment #94) > I would wait until we moved to Marionette as backend engine. I don't want > that necessary work like this gets obsolete in the next two quarters. We > should revisit then. Is there a bug tracking the status of landing the Marionette backend engine? If so, Mihaela, maybe you could file a bug to work on automated tests for this but make it blocked by the Marionette bug.
For now we have bug 996668 to prepare Mozmill for the transition. But there would still be other bugs to finish off afterward. What could be done here is some locally running Mozmill tests for now on an already setup machine which can connect via UNC to a remote machine. I think you can get a bug filed for the test, and we can figure out there how to get it implemented and running in the meantime.
(In reply to Henrik Skupin (:whimboo) from comment #96) > I think you can get a bug filed for the test, and we can figure out there how to get it implemented > and running in the meantime. Mihaela, can you please take care of this?
(In reply to Anthony Hughes, QA Mentor (:ashughes) [Away until 2014-04-28] from comment #97) > Mihaela, can you please take care of this? Logged bug 998290
We have a bug filed for a Mozmill test, so removing the in-qa-testsuite flag.
Flags: in-qa-testsuite?
You need to log in before you can comment on or make changes to this bug.