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

Status: VERIFIED FIXED

(Core :: DOM: Geolocation, defect)

Description

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

this was also seen by tracy during the testday and looks to be the same issue.

Comment 2

[Doug Turner (:dougt)]

Joel, are you able to reproduce this without the drag and drop step?

Comment 3

[Joel Maher ( :jmaher ) (UTC -8)]

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

Comment 4

[(not currently active) Ted Mielczarek]

I hit this without any drag/drop using dougt's demo page. It worked the first time, but not after that.

Comment 5

[Doug Turner (:dougt)]

it might be the way I am stashing the update object in the network channel.  ted, you able to repo?

Comment 6

[(not currently active) Ted Mielczarek]

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

Comment 7

[Doug Turner (:dougt)]

Attachment: 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.

Comment 8

[Doug Turner (:dougt)]

@ted, can you try this patch out?

Comment 9

[(not currently active) Ted Mielczarek]

If you throw it at the try server and point me to a build. Not enough bandwidth/time to do a build currently.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

(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?

Comment 11

[Doug Turner (:dougt)]

@gavin, i filed 490490 to investigate.

Comment 12

[Doug Turner (:dougt)]

http://hg.mozilla.org/mozilla-central/rev/f510e421b136

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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

No approval needed anymore since it's a blocker.

Comment 16

[Doug Turner (:dougt)]

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/38c2817eba84

Comment 17

[Henrik Skupin [:whimboo][⌚️UTC+1]]

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