[Bug 55669] Script includes should check window.mw

2014-08-28 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=55669

Krinkle krinklem...@gmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Assignee|wikibugs-l@lists.wikimedia. |krinklem...@gmail.com
   |org |
   Target Milestone|--- |1.24.0 release
   Severity|minor   |major

--- Comment #4 from Krinkle krinklem...@gmail.com ---
Fixed.

 resourceloader: Wrap only=script responses in if(window.mw)

 Change-Id: Icf6ede09b51ce212aa70ff6be4b341762ec75b4d

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 55669] Script includes should check window.mw

2013-10-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=55669

--- Comment #1 from Krinkle krinklem...@gmail.com ---
Depending on whether we work on bug 30358 first, this bug becomes moot.
Personally I'd prefer that.

The direct load.php requests embedded in the HTML, at least for scripts, are a
hack because they bypass the client-side loader and with that the
implementation logic and callback.

This is why we currently output additional script tags along side these (for
modules=site, user, user.groups etc.) to set the state to loading and/or
ready.

I'd much rather fix bug 30358, and keep the model that if you make a request to
load.php, unless you set raw=1, you are expected to handle mw.loader.implement.
If you can't (e.g. because the browser isn't compatible and didn't get the
mediawiki.loader payload) that request shouldn't be fired in the first place.

- It's a wasted request.
- Requires hardcoded script tags.
- Requires the mw.loader.state loading hacks in the html.

Of course, if bug 30358 takes too much to fix on the short term, we could work
around it by prefixing load.php responses with `window.mw`, but I'd rather
not as it masks errors and makes it harder to detect that the 3 points above
are required by the client.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 55669] Script includes should check window.mw

2013-10-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=55669

Krinkle krinklem...@gmail.com changed:

   What|Removed |Added

   Priority|Unprioritized   |Low
   Severity|normal  |minor

--- Comment #2 from Krinkle krinklem...@gmail.com ---
Lowering priority since these exceptions happen in a global and isolated
execution scope (doesn't affect other scripts, though even if it didn't, there
most likely aren't any other scripts), plus, they shouldn't be visible to
non-developers anyway (except for IE which in older versions does its This web
page has an error thing by default, though configurable).

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l


[Bug 55669] Script includes should check window.mw

2013-10-14 Thread bugzilla-daemon
https://bugzilla.wikimedia.org/show_bug.cgi?id=55669

Umherirrender umherirrender_de...@web.de changed:

   What|Removed |Added

 CC||umherirrender_de...@web.de

--- Comment #3 from Umherirrender umherirrender_de...@web.de ---
A RessourceLoader::makeLoaderConditionalScript function exists for this and it
is used in some places.

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l