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

VERIFIED FIXED in mozilla1.9.2a1



10 years ago
10 years ago


(Reporter: whimboo, Assigned: dougt)



1.9.1 Branch
Bug Flags:
blocking1.9.1 +

Firefox Tracking Flags

(Not tracked)




(1 attachment)

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

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.

Comment 2

10 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.

Comment 5

10 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, click "tell them", works
2) Load, click "tell them", get error
3) Reload, get the same error

Comment 7

10 years ago
Posted patch patch v.1Splinter Review
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?


10 years ago
Attachment #374831 - Flags: review? → review?(

Comment 8

10 years ago
@ted, can you try this patch out?
Attachment #374831 - Flags: review?( → 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?

Comment 11

10 years ago
@gavin, i filed 490490 to investigate.
Attachment #374831 - Flags: superreview?(jst) → superreview+


10 years ago
Attachment #374831 - Flags: approval1.9.1?

Comment 12

10 years ago
Last Resolved: 10 years ago
Resolution: --- → FIXED
Duplicate of this bug: 490740
Flags: blocking1.9.1? → blocking1.9.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
Target Milestone: --- → mozilla1.9.2a1
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?
Keywords: checkin-needed

Comment 16

10 years ago
Keywords: checkin-needed → fixed1.9.1
Keywords: fixed1.9.1 → verified1.9.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


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