Geolocation fails when link is dragged into another tab with "update is null"

VERIFIED FIXED in mozilla1.9.2a1

Status

()

Core
Geolocation
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: whimboo, Assigned: dougt)

Tracking

({verified1.9.1})

1.9.1 Branch
mozilla1.9.2a1
verified1.9.1
Points:
---
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090423 Shiretoko/3.5b4pre ID:20090423163827

When I do the following steps an error appears in the error console and the page is blank:

Error: update is null
Source File: file:///C:/Programme/Mozilla%20Firefox%203.5%20Beta%204/components/NetworkGeolocationProvider.js
Line: 218

Steps:
1. Drag&Drop the URL from the URL field to the tab bar to open a new tab or drop it over an already existing tab
2. Click the button "Tell them" inside the notification toolbar
3. Page is blank

This problem persist for the remaining time the browser is open. I can see this on Windows and OS X.
Flags: blocking1.9.1?
this was also seen by tracy during the testday and looks to be the same issue.
(Assignee)

Comment 2

8 years ago
Joel, are you able to reproduce this without the drag and drop step?
if I hit this error by drag and drop, any subsequent work results in the same error.  For example if I browse to a geolocation page after hitting this error and click "Tell them", it will give me the update is null error.

trying to reproduce this without the drag/drop step
I hit this without any drag/drop using dougt's demo page. It worked the first time, but not after that.
(Assignee)

Comment 5

8 years ago
it might be the way I am stashing the update object in the network channel.  ted, you able to repo?
Here are my STR:
1) Load http://people.mozilla.org/~dougt/geo.html, click "tell them", works
2) Load http://geo.webvm.net/, click "tell them", get error
3) Reload http://people.mozilla.org/~dougt/geo.html, get the same error
(Assignee)

Comment 7

8 years ago
Created attachment 374831 [details] [diff] [review]
patch v.1

no longer caching the update object, but instead just grabbing the global service.  Thinking about this a bit, we probably should redo the way geolocation providers push locations into the geolocation.  I will fix that up in bug 454490.

also, dropping the const on the xhr request because this really isn't a const object.

and, nulling the wifi_service when done with it.
Assignee: nobody → doug.turner
Attachment #374831 - Flags: superreview?(jst)
Attachment #374831 - Flags: review?
(Assignee)

Updated

8 years ago
Attachment #374831 - Flags: review? → review?(gavin.sharp)
(Assignee)

Comment 8

8 years ago
@ted, can you try this patch out?
Attachment #374831 - Flags: review?(gavin.sharp) → review+
If you throw it at the try server and point me to a build. Not enough bandwidth/time to do a build currently.
(In reply to comment #7)
> no longer caching the update object, but instead just grabbing the global
> service.

Do you know why the update ended up being null? Was the channel losing track of it somehow? Or was shutdown() called unexpectedly before onChange()? Or something else?
(Assignee)

Comment 11

8 years ago
@gavin, i filed 490490 to investigate.

Updated

8 years ago
Attachment #374831 - Flags: superreview?(jst) → superreview+
(Assignee)

Updated

8 years ago
Attachment #374831 - Flags: approval1.9.1?
(Assignee)

Comment 12

8 years ago
http://hg.mozilla.org/mozilla-central/rev/f510e421b136
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED

Updated

8 years ago
Duplicate of this bug: 490740
Flags: blocking1.9.1? → blocking1.9.1+
(Reporter)

Comment 14

8 years ago
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090504 Minefield/3.6a1pre ID:20090504031236
Status: RESOLVED → VERIFIED
Target Milestone: --- → mozilla1.9.2a1
(Reporter)

Comment 15

8 years ago
Comment on attachment 374831 [details] [diff] [review]
patch v.1

No approval needed anymore since it's a blocker.
Attachment #374831 - Flags: approval1.9.1?
(Reporter)

Updated

8 years ago
Keywords: checkin-needed
(Assignee)

Comment 16

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/38c2817eba84
Keywords: checkin-needed → fixed1.9.1
(Reporter)

Updated

8 years ago
Keywords: fixed1.9.1 → verified1.9.1
(Reporter)

Comment 17

8 years ago
Verified fixed with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090511 Shiretoko/3.5b5pre ID:20090511031352
(Assignee)

Updated

8 years ago
Duplicate of this bug: 492345
You need to log in before you can comment on or make changes to this bug.