In T53736#3389432, @Krinkle wrote:This proposal is to get rid of that and come up with something better. Solution 1 is to remove the logic that makes the server respond with the content of the target of the redirect and instead respond with a native browser redirect. This means the browser will be told, "nothing here, go to https://en.wikipedia.org/wiki/Foo_events#Foo_2017 instead.". The browser then essentially aborts the load, updates the browser bar, and goes to make another request to the server (transparent to the user). This solves the problem, but does come at the cost of performance. (As user's devices will now sending a request, getting a respond, and then doing the ceremony a second time.)
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jun 29 2017
Jun 29 2017
In T53736#3380977, @GWicke wrote:In T53736#3365130, @Zazpot wrote:In T53736#3349657, @GWicke wrote:In the past, we discussed adding the "redirected from" thing in client-side javascript.
It's unclear (to me) from this remark whether you spotted that the purpose of this issue is, at least in part, to handle cases where client-side JavaScript is not present (e.g. a browser that does not support JavaScript, or that has JavaScript disabled). Probably you already understood that, but I'm adding this clarificatory remark just in case not ;)
To clarify: I was talking about the "redirected from" notice, which at least the current description does not call out as needs-to-work-without-JS. While fundamental functionality like linking clearly shouldn't rely on JS, it might make sense to rely on JS for less critical features like small notices aimed primarily at editors, especially when that enables better cache performance.
Jun 28 2017
Jun 28 2017
s/implantated/implemented/ ?
Zazpot updated the task description for T169130: Prevent the addition of Property Constraints to Items.
Zazpot added a comment to T168968: [Story] Make Wikidata Query Service accessible without JavaScript.
In T168968#3386823, @Aleksey_WMDE wrote:TLDR: Currently it makes browser to download a result file in application/sparql-results+xml format, which is hard to understand and not what user would expect, IMO.
Jun 27 2017
Jun 27 2017
Zazpot added a comment to T168968: [Story] Make Wikidata Query Service accessible without JavaScript.
In T168968#3384067, @Jonas wrote:Could you please explain what the motivation behind this is and also what you expect to work without JS?
Zazpot updated the task description for T168968: [Story] Make Wikidata Query Service accessible without JavaScript.
Zazpot awarded T168968: [Story] Make Wikidata Query Service accessible without JavaScript a 100 token.
Zazpot awarded T53814: [Story] Allow editing of statements without JavaScript a 100 token.
Zazpot updated the task description for T168968: [Story] Make Wikidata Query Service accessible without JavaScript.
Jun 20 2017
Jun 20 2017
In T53736#3362847, @Tgr wrote:In T53736#3343170, @Krinkle wrote:Related use cases we don't want to break:
Also performance? A HTTP redirect would introduce delay for no good reason (unless we cache it in Varnish and then deal with cache invalidation).
[...] IMO the low-hanging fruit is to just change the text of the redirect warning as suggested in T53736#556866.
In T53736#3349657, @GWicke wrote:In the past, we discussed adding the "redirected from" thing in client-side javascript.
May 30 2017
May 30 2017
https://en.wikipedia.org/w/index.php?title=Feh_%28image_viewer%29&action=edit&undoafter=767731611&undo=782915510 produces an error message claiming that an edit conflict exists.
May 29 2017
May 29 2017
Zazpot awarded T7072: Paragraph splits and moves not identified in diffs a Manufacturing Defect? token.
Several people above have suggested that a client-side solution would be acceptable. I disagree.
As discussed here, another example of this bug is at https://en.wikipedia.org/w/index.php?title=MalwareTech&diff=782456060&oldid=782449642 . In that diff, both the left and right columns have hunks that begin "Following his work on the WannaCry ransomware attack in 2017" and that are almost identical (edit distance: 3) but that have been aligned with other hunks instead of with each other, making it very hard to spot what has changed between them. (To spare you searching, it is "he's" to "he has".)
Nov 22 2016
Nov 22 2016
Zazpot added a comment to T144781: Shortcuts that are redirects to anchors are broken without JavaScript enabled.
In T144781#2812569, @Tgr wrote:everyone has Javascript these days
Sep 8 2016
Sep 8 2016
User 24.151.10.165 has added a note about this issue on my talk page.
Sep 6 2016
Sep 6 2016
Zazpot added a comment to T144781: Shortcuts that are redirects to anchors are broken without JavaScript enabled.
Related to T2218, according to 24.151.10.165.
Zazpot added a comment to T144781: Shortcuts that are redirects to anchors are broken without JavaScript enabled.
here's an edit from 2011 that documents this behavior on the English Wikipedia
Lahwaacz wrote:
Is the "Redirected from" message really more important than breaking links for browsers with JavaScript disabled? JavaScript should be used to enhance functionality and not to break stuff. Isn't it possible to do it the opposite way and add the "Redirected from" message using a JavaScript when the page was loaded through a HTTP redirect?
Zazpot added a comment to T144781: Shortcuts that are redirects to anchors are broken without JavaScript enabled.
matmarkex wrote:
That's not true. Redirects to section always relied on JavaScript, even before that change.
Zazpot added a comment to T144781: Shortcuts that are redirects to anchors are broken without JavaScript enabled.
Aklapper wrote:
If they "are currently broken" and do not work, what does that mean? That you still end up on the correct page, just not scrolling to the correct position?
From the user perspective this would have a similar effect to using 301s. It would make end users end up copying the canonical url instead of the redirect's url.
Sep 5 2016
Sep 5 2016
Jul 24 2016
Jul 24 2016
In T44085#2490185, @Legoktm wrote:In T44085#2487131, @Zazpot wrote:Can I ask that the fix [...] prevent the shortened URLs containing characters that are ambiguous in common fonts [...]
Yes, that's already implemented. See T139511: Remove 0 and O from the list of characters as they are visually confusing for some more details.
Jul 22 2016
Jul 22 2016
Can I ask that the fix for this feature request implement something like newbase42 (which is abandonware, but the principle is clear) in order to prevent the shortened URLs containing characters that are ambiguous in common fonts, such as these characters:
Il10O
Content licensed under Creative Commons Attribution-ShareAlike (CC BY-SA) 4.0 unless otherwise noted; code licensed under GNU General Public License (GPL) 2.0 or later and other open source licenses. By using this site, you agree to the Terms of Use, Privacy Policy, and Code of Conduct. · Wikimedia Foundation · Privacy Policy · Code of Conduct · Terms of Use · Disclaimer · CC-BY-SA · GPL