[nsIXMLHttpRequest.send] error while running Geolocation test in PB mode

RESOLVED WORKSFORME

Status

()

Product:
Core
Component:
DOM: Geolocation
Type:
defect
Status:
RESOLVED WORKSFORME
Opened:
10 years ago
Updated:
4 years ago

People

(Reporter: marcia, Unassigned)

Tracking

Version:
1.9.1 Branch
Platform:
x86
macOS
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(
URL
) 

Seen while running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b99) Gecko/20090604 Firefox/3.5b99

STR:
1. Enter PB mode.
2. Launch the test site in the URL field
3. Observe Error

Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIXMLHttpRequest.send]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: file:///Users/marcia/Desktop/RC/Firefox.app/Contents/MacOS/components/NetworkGeolocationProvider.js :: anonymous :: line 261"  data: no]
Source File: file:///Users/marcia/Desktop/RC/Firefox.app/Contents/MacOS/components/NetworkGeolocationProvider.js
Line: 261

The error on Line: 261 correlates to xhr.send(jsonString);

Running a pretty fresh profile with one extension installed, a Master Password set and FIPS mode enabled.
So I do not see this same error running the latest nightly,  Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090605 Shiretoko/3.5pre.

Using 3.5b99 I disabled FIPs and the one extension I installed and the error still shows.

Adding Ehsan since I only see the error in PB mode.
Can you run the same test on a fresh profile as well?
Using a fresh profile running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b99) Gecko/20090604 Firefox/3.5b99->

I do not get that error, but rather Error: JSON.parse
Source File: file:///Users/marcia/Desktop/RC/Firefox.app/Contents/MacOS/components/NetworkGeolocationProvider.js Line: 209

Line: 209 corresponds to: // if we get a bad response, we will throw and never report a location var response = JSON.parse(req.target.responseText);

Will try the latest nightly next.
Using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090605 Shiretoko/3.5pre with a fresh profile I get no errors in the console, so it is different than what I see using the Build in Comment 3.

Same thing happens using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090605 Minefield/3.6a1pre with a fresh profile.
This is Mac-specific; I can't reproduce it on Windows using a b99 build with a fresh profile...

(In reply to comment #4)
> Same thing happens using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
> rv:1.9.2a1pre) Gecko/20090605 Minefield/3.6a1pre with a fresh profile.

You mean no errors observed, right?
I cannot see this error when running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090607 Shiretoko/3.5pre ID:20090607030919

Marcia, do you still see this problem? If yes, you should enable the geolocation logging and check if we send the correct string.
How do I enable the geolocation logging?
Uncomment the two lines in the function 'log', here:

http://mxr.mozilla.org/mozilla-central/source/dom/src/geolocation/NetworkGeolocationProvider.js?mark=12-13

Then rebuild :) (or you can modify the jar file itself, but that's slightly more involved IMO)
Marcia, it's something like:

"vi /Applications/Shiretoko.app/Contents/MacOS/components/NetworkGeolocationProvider.js"

After a restart you will find the output in the Error Console. Please mail it to me since it contains private data.
Mmh I wonder how fast you are Marcia. Have you requested the location right before entering the PB mode? So probably a running request is still in work. That could be possible when looking at:

http://mxr.mozilla.org/mozilla-central/source/content/base/src/nsXMLHttpRequest.cpp#2485

Don't we cancel requests when switching into PB mode?
As Henrik notes in Comment 10, I am not certain whether I visited the test site first in regular mode before entering PB mode. Right now I am not able to reproduce the issue but will keep trying.  Meanwhile I will also enable the logging.

Regarding Comment 5, yes I meant no errors.
Performing the following steps, I could not reproduce the error provided in comment #0 within multiple builds across OS X (as well, tested in Linux [b99])

Tested in latest 1.9.1 branch, trunk and b99 preview

1. Create a new profile
2. Entered PB mode
3. Went to bug's URL
4. Shared location, let it load for a minute
5. Checked error console

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090608 Shiretoko/3.5pre

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b99) Gecko/20090604 Firefox/3.5b99

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090608 Minefield/3.6a1pre

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99
I experienced the same error as the reporter when my ISP was experiencing problems. My router was giving me an IP address, so Firefox thought it was online, but it seemed like it was giving this error when it couldn't contact the location provider.

I'm not on that computer now, so don't have a UA string, but it was 3.5b4 on an Intel Mac.
I can reproduce the error easily using Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2.

With a fresh profile,
1. Start Private Browsing
2. Load http://maps.google.com/ and click the small circle below the navigation pad at the top.
3. Receive the error.
The other things I have enabled are:

1. Master Password + FIPS turned on.

I had installed Firebug and Adblock plus, but I disabled both issues and I still see the error in Comment 14.
marcia, can you show me this tomorrow/monday?
I am actually seeing this error with the 3.6 beta build - I will show the issue to dougt in the machine in the lab. I am running Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2b1) Gecko/20091019 Firefox/3.6b1.
Rechecked with modern private browsing mode and http://html5demos.com/geo this works. The code in question is wrapped in a try and properly notifies an error upstream should the xhr fail.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.