Almost all links in a navbox marked as red on a specific page
Closed, ResolvedPublic1 Story Points

Description

I have no idea what's causing this, but in https://en.wikipedia.org/w/index.php?title=User:Matma_Rex/sandbox&oldid=785699590 almost all links in the navbox templates are being marked as red. All of these pages actually exist, and they are marked correctly on other pages (e.g. https://en.wikipedia.org/wiki/Law_of_Gravity_(CSI:_Crime_Scene_Investigation)).

Restricted Application added a project: VisualEditor. · View Herald TranscriptJun 15 2017, 12:16 AM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
matmarex updated the task description. (Show Details)Jun 15 2017, 12:16 AM
Deskana changed the task status from Open to Stalled.Jun 15 2017, 1:01 PM
Deskana added a subscriber: Deskana.

I can't reproduce this problem; when I go to the revision in the description, everything looks fine.

@Nnvu I only see this issue on specific pages, rather than everywhere. Is it the same for you? Can you five a few examples of broken pages?

Interestingly, while it's not visible normally because of the node highlights overlaid on top of the template, the links actually point to subpages of my user page – e.g. https://en.wikipedia.org/wiki/User:Matma_Rex/CSI:_Crime_Scene_Investigation_(season_1) and so on. And VE runs API queries to check the status of those pages, which indeed do not exist. (Even more interesting why some of them, like https://en.wikipedia.org/wiki/User:Matma_Rex/D.B._Russell, are considered to exist…)

I vaguely recall Ed making some changes in this area recently.

Nnvu added a comment.EditedJun 28 2017, 11:10 PM

@Nnvu I only see this issue on specific pages, rather than everywhere. Is it the same for you? Can you five a few examples of broken pages?

I have this issue in every page in itwiki: when editing with VE the links in templates are almost all red. But if I change something in the template every link becomes blue.

Nnvu added a comment.Jun 30 2017, 5:02 PM

On itwiki the issue is (apparently) solved.

Nnvu added a comment.Jun 30 2017, 5:13 PM

On itwiki the issue is (apparently) solved.

I was wrong. Apparently, on some pages the wikilinks are red in templates

Editing with VE

Saved page

Nnvu added a comment.Jul 3 2017, 11:27 PM

I don't know if this helps, but I've noticed that the red links in itwiki are red because the link has a class="new" that makes it red

Elitre added a comment.Jul 4 2017, 2:28 PM

Is this still happening, Nnvu? I can't reproduce in any browsers or while logged out, with the same article.

Nnvu added a comment.Jul 4 2017, 2:42 PM

I can only reproduce the error if the URL contains something "extra". I cannot reproduce it in https://it.wikipedia.org/wiki/Mookie_Betts but I can reproduce it in https://it.wikipedia.org/w/index.php?title=Mookie_Betts&oldid=88755040

matmarex claimed this task.Jul 4 2017, 4:30 PM

I still see the problem with my original example. I'll look into that and we'll see if that also fixes the it.wp issues.

This is a Chrome-specific issue. I can reproduce the problem in Opera beta 47 (Chromium 60), all other browsers I checked behave correctly (Firefox, Opera 12, IE 11, Edge).

In documents created dynamically using DOMParser, <base> tags with protocol-relative href attribute are apparently ignored. This causes <a> tags' href property to resolve relative to the current document rather than the given base. This results in the issue we see if the page is being viewed under /w/ or if it is a subpage. Note that the issue does not occur if you just view the document with such <base> tag directly.

Minimal test case:

html = '<!DOCTYPE html><html><head><base href="//example.com/"/></head><body><a href="./foo">foo</a></body></html>';
doc = new DOMParser().parseFromString( html, 'text/html' );
console.log( doc.getElementsByTagName( 'a' )[ 0 ].href );

This should output https://example.com/foo. In buggy browsers, it will instead output an URL based on the current page's URL.

Slightly less minimal test case, closer to the code that we use in VE:

mw.loader.using( 'ext.visualEditor.base' ).done( function () {
	ajax = $.ajax( 'https://en.wikipedia.org/api/rest_v1/page/html/User%3AMatma_Rex%2Fsandbox?redirect=false' );
	ajax.done( function () {
		doc = ve.createDocumentFromHtml( ajax.responseText );
		console.log( doc.getElementsByTagName( 'a' )[ 0 ].href );
	} );
} );

I don't know why this appeared now – did Parsoid start generating these protocol-relative bases recently, or is the bug in Chrome new?

Change 363227 had a related patch set uploaded (by Bartosz Dziewoński; owner: Bartosz Dziewoński):
[VisualEditor/VisualEditor@master] ve.fixBase: Fix protocol-relative base href for Chrome

https://gerrit.wikimedia.org/r/363227

ssastry added a subscriber: ssastry.Jul 5 2017, 5:18 PM

This is a Chrome-specific issue. I can reproduce the problem in Opera beta 47 (Chromium 60), all other browsers I checked behave correctly (Firefox, Opera 12, IE 11, Edge).
...
I don't know why this appeared now – did Parsoid start generating these protocol-relative bases recently, or is the bug in Chrome new?

No recent changes in Parsoid land here. Protocol-relative base has been there for quite a while now.

matmarex changed the task status from Stalled to Open.Jul 5 2017, 9:24 PM
Catrope added a subscriber: Catrope.Jul 5 2017, 9:36 PM

I know about this, and it's "not a bug" in Chrome. It depends on what you consider the parent of the DOMParser document to be. In Firefox, it's the viewport document, in Chrome it's nothing. Protocol-relative base URIs are defined to inherit their protocol from the parent document's base URI, but in Chrome there is no parent document.

For this reason, I swear I had put code in VE that resolves/absolutizes the base URI of the Parsoid document in the context of the viewport document. Did that code get removed?

For this reason, I swear I had put code in VE that resolves/absolutizes the base URI of the Parsoid document in the context of the viewport document. Did that code get removed?

No, it's right there in ve.fixBase, but it doesn't work any more because Chrome changed its behavior.

if ( !targetDoc.baseURI || targetDoc.baseURI === 'about:blank' ) {
    baseNode.setAttribute( 'href', ve.resolveUrl( baseNode.getAttribute( 'href' ), sourceDoc ) );

I put that there specifically because of the Chrome behavior you describe. targetDoc.baseURI was falsey because of the invalid base and the parentage issue that I described. But Chrome changed, and targetDoc.baseURI is now the URI of the viewport document, which is very wrong.

Change 363227 merged by jenkins-bot:
[VisualEditor/VisualEditor@master] ve.fixBase: Fix protocol-relative base href for Chrome

https://gerrit.wikimedia.org/r/363227

Change 363691 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1934b77e7)

https://gerrit.wikimedia.org/r/363691

Change 363691 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1934b77e7)

https://gerrit.wikimedia.org/r/363691

Jdforrester-WMF set the point value for this task to 1.
Jdforrester-WMF moved this task from To Triage to TR0: Interrupt on the VisualEditor board.
Jdforrester-WMF added a subscriber: Jdforrester-WMF.

Work-around for upstream bug is merged; @Deskana, do you want to declare this one as "Resolved"?

Deskana closed this task as Resolved.Jul 7 2017, 11:36 AM

Works for me.

Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptJul 7 2017, 11:36 AM

The upstream issue has been fixed and the fix seems to be destined for Chromium 62.