Page MenuHomePhabricator

Respond with valid JS/CSS on redirects when using action=raw&ctype=text/css or action=raw&ctype=text/javascript
Closed, InvalidPublic

Description

This is a followup for T32074: Redirecting css/js wiki pages shouldn't cause syntax errors when loaded as a module..

I think it would be better if the result of using "action=raw&ctype=text/javascript" or "action=raw&ctype=text/css" were changed to output nothing (or just an informative comment) if the target page is a redirect. This way the users who import a page which was moved will not have broken scripts and stylesheets.

Would that be feasible by some change similar to https://static-codereview.wikimedia.org/MediaWiki/94155.html ?


Version: unspecified
Severity: normal
URL: https://en.wikipedia.org/w/index.php?title=MediaWiki:Sysop.css&diff=prev&oldid=456378679
See Also:
T36930: Suppress redirects when moving *.js and *.css pages during a user rename

Details

Reference
bz31827
TitleReferenceAuthorSource BranchDest Branch
Update function-schemata sub-module to HEAD (5f40813)repos/abstract-wiki/wikifunctions/function-evaluator!29jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (5f40813)repos/abstract-wiki/wikifunctions/wikilambda-cli!12jforrestersync-function-schematamain
fab: build images with user dockerpkg-builderrepos/releng/dev-images!39hasharfab-shared-usermain
Add rate limiter in the evaluator.repos/abstract-wiki/wikifunctions/function-evaluator!23apineapine-rate-limitmain
BREAKING CHANGE: Update function-schemata sub-module to HEAD (63aa93e)repos/abstract-wiki/wikifunctions/function-orchestrator!35apineapine-sync-function-schematamain
Limit call stack size in the orchestrator when the number of operations associated with a single function call exceeds a threshold.repos/abstract-wiki/wikifunctions/function-orchestrator!34apineapine-rate-limitmain
Add errors for rate limits in backend services.repos/abstract-wiki/wikifunctions/function-schemata!19apineapine-rate-limitsmain
Update function-schemata sub-module to HEAD (19f2a6d)repos/abstract-wiki/wikifunctions/wikilambda-cli!10jforrestersync-function-schematamain
Update function-schemata sub-module to HEAD (19f2a6d)repos/abstract-wiki/wikifunctions/function-evaluator!21apinesync-function-schematamain
Update function-schemata sub-module to HEAD (19f2a6d)repos/abstract-wiki/wikifunctions/function-orchestrator!28apinesync-function-schematamain
Implement Filter, Map, and Reduce builtin functions.repos/abstract-wiki/wikifunctions/function-orchestrator!27apineapine-map-reduce-2main
Create Z2/Persistent Object for the Filter function.repos/abstract-wiki/wikifunctions/function-schemata!17apineapine-map-reduce-2main
Advance Avro schema version to 0.0.5 and Add request-id to Invariantsrepos/abstract-wiki/wikifunctions/function-orchestrator!26apineapine-request-idmain
Add requestID to Avro schema.repos/abstract-wiki/wikifunctions/function-schemata!16apineapine-serializationmain
Draft: Implement Map and Reduce builtin functions.repos/abstract-wiki/wikifunctions/function-orchestrator!25apineapine-map-reducemain
Create Z2/Persistent Objects for the Map and Reduce functions.repos/abstract-wiki/wikifunctions/function-schemata!15apineapine-map-reducemain
Show related patches Customize query in GitLab

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:56 PM
bzimport set Reference to bz31827.
bzimport added a subscriber: Unknown Object (MLST).

I'm pretty sure that would still by definition break their scripts/styles by removing them...?

At least it wouldn't cause syntax errors as currently happens, breaking other scripts as well.

Syntax errors shouldn't be breaking other scripts unless they're being bundled together in ResourceLoader and somebody disabled the JS validity checks.

If they're coming from action=raw, then they're not going through ResourceLoader's bundling at all -- so a failure should only halt execution of that script, not any others.

An error message on your JS console will however alert you to the presence of an error, won't it? Seems like it would be useful for helping people to find their broken scripts.

(In reply to comment #2)

...breaking other scripts as well.

Er.. I just checked this with a code like the following on my /common.js

mw.loader.load( 'http://localhost/mw18/index.php?title=MediaWiki:Test1.js&action=raw&ctype=text/javascript' );
mw.loader.load( 'http://localhost/mw18/index.php?title=MediaWiki:Test2.js&action=raw&ctype=text/javascript' );

and then moving "MediaWiki:Test1.js" to another name. As you explained, this didn't break "MediaWiki:Test2.js", so never mind...

(In reply to comment #1)

I'm pretty sure that would still by definition break their scripts/styles by
removing them...?

Why not actually making redirects work in css and js pages? Is there anything that makes this fundamentally more complicated than other cases? By now we're using redirects for pages, images, templates, and it all works seamlessly.

(In reply to comment #5)

Why not actually making redirects work in css and js pages? Is there anything
that makes this fundamentally more complicated than other cases? By now we're
using redirects for pages, images, templates, and it all works seamlessly.

+1.

I've openned bug 33973 requesting that.

Example urls:

(In reply to comment #5)

(In reply to comment #1)

I'm pretty sure that would still by definition break their scripts/styles by
removing them...?

Why not actually making redirects work in css and js pages? Is there anything
that makes this fundamentally more complicated than other cases? By now we're
using redirects for pages, images, templates, and it all works seamlessly.

Because contrary to all of the above, CSS and javascript are not Wiki-specific objects. They are native scripts interpreted by the browser - while at the same time being an ordinary wikipage that should be editable, watchable, and... redirectable (when viewing normally).

I've wontfixed bug 33973 (see reason there), and re-opening this one.

We should make action=raw respond with valid CSS or JavaScript when requesting ctype=text/css or ctype=text/javascript on a redirect. Just like we used to do for non-existent ones (by reponding with HTTP 200 OK; Content: /* Empty */; - instead of HTTP 404 Not Found).

For redirects we can do something like HTTP 200 OK: Content: /* Redirect */

It is important that this only happens for those content types. In other cases it should respond with the original wikitext as expected, as other wise it could break bots and scripts.

(In reply to comment #7)

For redirects we can do something like HTTP 200 OK: Content: /* Redirect */

In that case, make sure the "Redirect" text is in site language (as in bug 28937).

Pppery closed this task as Invalid.EditedNov 5 2023, 11:25 PM
Pppery subscribed.

Closing as obsolete following T73200: Support redirects in JavaScriptContent, meaning that now the redirect from moving a JS page is valid JavaScript.