| matmarex | |
| Jun 15 2017, 12:16 AM |
| F8613139: Immagine.png | |
| Jul 3 2017, 11:27 PM |
| F8581321: Immagine.png | |
| Jun 30 2017, 5:13 PM |
| F8581327: Immagine1.png | |
| Jun 30 2017, 5:13 PM |
| F8462749: Screen Shot 2017-06-15 at 14.00.09.png | |
| Jun 15 2017, 1:01 PM |
| F8461206: image.png | |
| Jun 15 2017, 12:16 AM |
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)).
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.
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.
I was wrong. Apparently, on some pages the wikilinks are red in templates
Editing with VE
Saved page
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
Is this still happening, Nnvu? I can't reproduce in any browsers or while logged out, with the same article.
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
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
No recent changes in Parsoid land here. Protocol-relative base has been there for quite a while now.
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?
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
Change 363691 had a related patch set uploaded (by Jforrester; owner: Jforrester):
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1934b77e7)
Change 363691 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Update VE core submodule to master (1934b77e7)
Work-around for upstream bug is merged; @Deskana, do you want to declare this one as "Resolved"?