Page MenuHomePhabricator

Erreur non spécifiée. / Argument non valide. on Edge 18
Closed, InvalidPublic

Description

Impact: Edge 17 and 18

When visiting https://fr.wikipedia.org/wiki/Classe_Arleigh_Burke on Edge 18 in browser stack I get a generic error thrown in my developer console (replicated on browser stack). This error has no stack trace.

Do we want to disable error handling for such errors or for Edge 17/18?
https://api.jquery.com/jQuery.readyException/

https://logstash.wikimedia.org/app/kibana#/doc/logstash-*/logstash-2020.10.07/clienterror/?id=AXUE9qBtLNRtRo5XuJEP

Event Timeline

Krinkle subscribed.

Untagging. Does not appear related to the $.client.profile() method.

What is the relation with jQuery.readyException?

Is the error you get in the repro related to the one we see in Logstash?

Is it limited to frwiki? Is it frequent?

I too can reproduce this on frwiki, using the URL from the Logstash report: https://fr.wikipedia.org/wiki/L%C3%A9onard_de_Vinci

It also happens in debug mode. When breaking on exceptions, I do get the original trace (which Edge is not exposing to onerror for security reasons, but is available in the Dev Tools in Edge). The trace has 10 layers of promise/async traces, leading upto a mw.hook#add() call, but it doesn't say which one, and I'm unable to modify the code early enough to insert a custom breakpoint.

Trying a different approach. I can't reproduce it with safemode=on, which suggests there is a site script or default-gadget at play.

When loading the four user-generated modules one by one, I see which one is causing it. calling register()/load() for "site", "ext.gadget.ArchiveLinks", "ext.gadget.MonobookToolbarStandard", and "ext.gadget.Wdsearch".

The error happens when loading "ext.gadget.ArchiveLinks". When loading it from the console, the erorr is attributed to script.onerror (from mw.loader.addScript, as called internally by mw.loader.load), which is actually the first one to catch the error and then re-throws it. But Edge is not able to breakpoint on the native error that triggered script.onerror. This would normally be for things like request timeouts or network failures, but that is not the case here since we are able to reproduce it consistently.

Trying to narrow down what the problem is with with Gadget-ArchiveLinks.js, I copy the code and run it directly from the console. The native error still happens and is now attributed to a line number. It's this line of code:

$content.find( '.external' ).each( function ( _, link ) {
  if ( link.tagName !== 'A' ) {
    return;
  }

  var chemin = link.href;

  if ( /(^|\.)wiki([pm]edia|data)\.org$/.test( link.hostname )                                               ^

The link variable here is an HTMLAnchorElement object, which provides Location-like properties such as hostname and path that are automatically computed by the browser based on poarsing the href, expanding it relative to the document (if relative), and then returning the computed part of the URL (e.g. hostname).

I refreshed (needed, since the browser caches/avoids the error the second time), and re-ran the script with a console.log() statement for the href value.

The faulty external link is:

http://%5B%5Bs:it:Trattato%20della%20Pittura%20(da%20Vinci)/Parte%20terza%20-%20De'%20vari%20accidenti%20e%20movimenti%20dell'uomo%20e%20proporzione%20di%20membra/456.%20Della%20prospettiva%20lineare%7Clangue=Italien%7Cconsulté%7CTrattato%20della%20Pittura%20(da%20Vinci)/Parte%20terza%20-%20De'%20vari%20accidenti%20e%20movimenti%20dell'uomo%20e%20proporzione%20di%20membra/456.%20Della%20prospettiva%20lineare%7Clangue=Italien%7Cconsulté%5D%5D%20le%20=5%20septembre%202010

from the HTML source:

<li id="cite_note-113"><span class="mw-cite-backlink noprint"><a href="#cite_ref-113"></a> </span><span class="reference-text"><span class="ouvrage"><a rel="nofollow" class="external text" href="http://%5B%5Bs:it:Trattato%20della%20Pittura%20(da%20Vinci)/Parte%20terza%20-%20De&#39;%20vari%20accidenti%20e%20movimenti%20dell&#39;uomo%20e%20proporzione%20di%20membra/456.%20Della%20prospettiva%20lineare%7Clangue=Italien%7Cconsulté%7CTrattato%20della%20Pittura%20(da%20Vinci)/Parte%20terza%20-%20De&#39;%20vari%20accidenti%20e%20movimenti%20dell&#39;uomo%20e%20proporzione%20di%20membra/456.%20Della%20prospettiva%20lineare%7Clangue=Italien%7Cconsulté%5D%5D%20le%20=5%20septembre%202010">«&#160;<cite style="font-style:normal;">Trattato_della_Pittura</cite>&#160;»</a></span></span>

From the wikitext:

<ref>{{Lien web | titre = Trattato_della_Pittura | url=[[s:it:Trattato della Pittura (da Vinci)/Parte terza - De' vari accidenti e movimenti dell'uomo e proporzione di membra/456. Della prospettiva lineare|langue=Italien|consulté|Trattato della Pittura (da Vinci)/Parte terza - De' vari accidenti e movimenti dell'uomo e proporzione di membra/456. Della prospettiva lineare|langue=Italien|consulté]] le =5 septembre 2010 }}</ref>

This is just bad user input in wikitext making an external link that starts with a square bracket in the part for the domain name e.g. <a href="http://[[s:it:Trattato…"></a>. Where the frwiki templates is adding http:// in front of it, for the purpose of supporting user mistakes such as copying a url without the procol from the address bar (thanks for browsers often hiding this by default), whcih we then transport all the way as an excotic hostname, and Edge's URL native parser goes kaboom on it.