Page MenuHomePhabricator

Special:Nearby fails with "Module not found" error when there is no location permission
Closed, ResolvedPublic

Description

Without the permission to share location, Special:Nearby causes (both on mobile and on desktop) the below error in the JavaScript console, and results in an empty page (no content beyond the skin elements).

Instead, it should display an error message to the user, preferably with a link to an explanation about the feature that clarifies its privacy-preserving nature, analogous to the one in the Apps FAQ ("How does Nearby work? When you click Nearby, the app then gets instant access to your geolocation, and offers you a list of articles that are near your location. Nearby doesn't track your location or store your geodata.")

(See also T56172 )

Below is the JavaScript console output for https://en.wikipedia.org/wiki/Special:Nearby in Chromium on Linux; also reproduced the behavior in Firefox under OS X (with a similar console error message), and in Firefox mobile under Android (for both en.m.wikipedia and the desktop site).


Exception in module-execute in module mobile.startup:
load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:176 
Error: Module not found: settings 
Error: Module not found: settings {stack: "Error: Module not found: settings↵    at Object.Mo…cripts&skin=vector&version=20150515T062222Z:4:681", message: "Module not found: settings"}
message: "Module not found: settings"
stack: (...)
get stack: function () { [native code] }arguments: nullcaller: nulllength: 0name: ""prototype: StackTraceGetter__proto__: function Empty() {}<function scope>
set stack: function () { [native code] }
__proto__: dconstructor: function Error() { [native code] }message: ""name: "Error"toString: function toString() { [native code] }__proto__: Object load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:176 
log load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:153 
handler load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:45 
jQuery.Callbacks.fire load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:46 
jQuery.Callbacks.self.fireWith load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:46 
jQuery.Callbacks.self.fire load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:153 
mw.track load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:161 
runScript load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:162 
execute load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:168 
mw.loader.implement VM117:91 
(anonymous function) load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:4 
(anonymous function) load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:4 
jQuery.extend.globalEval load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:164 
mw.loader.work load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:162 
request load.php?debug=false&lang=en&modules=jquery%2Cmediawiki&only=scripts&skin=vector&version=20150515T0…:170 
mw.loader.load Special:Nearby:29 
(anonymous function)

Event Timeline

Tbayer raised the priority of this task from to Needs Triage.
Tbayer updated the task description. (Show Details)
Tbayer added a project: MobileFrontend.
Tbayer added a subscriber: Tbayer.
Restricted Application added a subscriber: Aklapper. · View Herald Transcript

This seems like a duplicate of T98594, which I'll try to get deployed today. /cc @kaldari

Thanks Sam! That looks indeed like a duplicate (I hadn't found it before filing this, probably because I only searched for open tickets - is it custom to close a bug before the patch is deployed?).

I might file the part about a more explanatory error message separately, but it should be find to close this one.

phuedx claimed this task.
phuedx added a subscriber: Jdlrobson.

is it custom to close a bug before the patch is deployed?

That's a very good question. If you'll permit the nuance: I think we settled on it without discussion – as I'm the Tech Lead, I'm probably a driver of it. We shouldn't though. Bug fixes are only Done when the bug is fixed, not when the code is merged.

@Jdlrobson: Whaddya reckon?

I might file the part about a more explanatory error message separately, but it should be find to close this one.

Ta and ta.

is it custom to close a bug before the patch is deployed?

That's a very good question. If you'll permit the nuance: I think we settled on it without discussion – as I'm the Tech Lead, I'm probably a driver of it. We shouldn't though. Bug fixes are only Done when the bug is fixed, not when the code is merged.

A bug is fixed when it's fixed on master, not when $my_favourite_wiki_farm has updated to the latest copy of the software that includes it. You are expected to close when it's fixed, not when your organisation has updated its own wikis.

What @Krenair said. I usually use the ready for sign off/done column to manage this in a current sprint.

@Krenair: Is that written down anywhere other than here?

This same bug has now been reported twice (and another bug has recently been reported three times) because we close 'em when the code is merged. Maybe the bug should be kept open bug in a We're gonna deploy this real soon column. Alternatively, we could keep an on-wiki list of upcoming updates that we can direct users to before raising bugs.

No, it doesn't need to be. Closing bugs only when you've deployed the patch to your own wiki group makes no sense as you're developing for multiple wikis. Also, bug tracking is for developers, not system administrators, and master is the development branch. You should be keeping track of patches you need to deploy to wikis where you are a sysadmin externally, it is not a matter for developers.