mediawiki.Uri does not support IPv6 URIs:
> var uri = new mw.Uri( 'http://127.0.0.1/' ) undefined > var uri = new mw.Uri( 'http://[::1]/' ) Error: Bad constructor arguments
Description
Description
Details
Details
- Reference
- bz64884
Related Changes in Gerrit:
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| mediawiki.Uri: Support IPv6 parsing | Esanders | mediawiki/core | master | +21 -2 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Declined | None | T66884 mediawiki.Uri does not support IPv6 URIs | |||
| Resolved | Krinkle | T103379 Add 'url' module for native URL constructor (with conditionally loaded polyfill) |
Event Timeline
Comment Actions
On a MediaWiki installation with IPv6 URL like
http://[::1]/w/index.php
the class mw.Uri gets not created because it is initialized with
mw.Uri = mw.UriRelative( document.location.href );
Comment Actions
This urfaces as TypeError: can't access property "clone", defaultUri is undefined and Unable to get property 'clone' of undefined or null reference https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-2020.10.14/clienterror/?id=AXUm60RcLNRtRo5XyfQb
Comment Actions
We don't run with IPv6 URLs in prod, we use hostnames like "wikipedia.org".
I'll be a different issue frrom whatever the caller is in that trace, please file a separate task.
Comment Actions
Change 759635 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/core@master] Support IPv6 in mw.Uri parsing
Comment Actions
Change 759635 abandoned by Krinkle:
[mediawiki/core@master] mediawiki.Uri: Support IPv6 parsing
Reason:
Done.
Comment Actions
Is there plans to replace mw.Uri by URL?
I was interested by this task because my test installation is https://[::1]/mediawiki/master/index.php (I like edge cases), and the VisualEditor was failing and is still failing since it still uses mw.Uri, but more generally there are a lot of users of mw.Uri. (no issue for myself, I know how to circumvent this issue by using 127.0.0.1 when needed.)
Comment Actions
@Seb35 Yes and no. The two are not directly compatible, but are similar enough that it's easy for developers to change one to the other in cases where edge cases are known to happen. For example, the VisualEditor team is doing this at T305010.
There are no plans at this time to mass-replace or deprecate mw.Uri. It's a stable module that incurs essentially no maintenance cost for our team to keep providing for a long time as-is. Expect handling of regressions and security issuse, and e.g. any regular maintenance as needed to keep up with external changes (coding practices, browser support etc.). A major shift to support IPv6 with a new internal parser that is yet also backwards-compatible is not currently planned to take place.
Comment Actions
Thanks for the answer. It’s indeed more safe not to mass-replace since there are different dialects of URLs (I discovered recently this not-issue in curl and this document about URL interoperability issues).
Comment Actions
I did T305010 for DiscussionTools mostly as an exercise for myself while learning how to use the URL API. But we also had several workarounds for mw.Uri bugs, so it seemed like a good thing from a maintenance perspective.
I wasn't planning to make similar changes in VisualEditor, but if you'd also enjoy some exercise ;) , then I'd be happy to review a patch. Generally I don't like making such changes, since they're error-prone, but it's a different thing if it's also fixing a bug (like the editor not loading on IPv6 wikis).