VisualEditor: Respect Parsoid's <base>
Closed, ResolvedPublic

bzimport set Reference to bz48915.
Jdforrester-WMF created this task.Via LegacyMay 28 2013, 10:19 PM
Catrope added a comment.Via ConduitMay 28 2013, 10:26 PM

Timo says we can get the browser to do the resolution by getting the .href and .src properties in the original Parsoid document, so all we need to do is figure out which attributes are affected. I can think of href and src, are there others?

Jdforrester-WMF added a comment.Via ConduitJun 26 2013, 6:07 PM
  • Bug 50216 has been marked as a duplicate of this bug. ***
Jdforrester-WMF added a comment.Via ConduitJul 5 2013, 12:42 AM
  • Bug 50764 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitAug 5 2013, 12:29 PM
  • Bug 51585 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitAug 5 2013, 12:29 PM
  • Bug 51122 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitAug 5 2013, 12:30 PM

Come on guys, this is "high major" since May.

Thryduulf added a comment.Via ConduitAug 5 2013, 12:35 PM

To hopefully help people find this bug, here is the description from bug 51122 "link targets assumed to be same namespace when opened with ctrl+click" updated to reflect that it now happens with all links, not just those in image captions:

When opening a link from the editing interface using ctrl+click (or "open in a new tab" from the right button menu) the link target is assumed to be in the same namespace as the currently edited page.

For example a link to [[Bridgnorth Cliff Railway]] from the page [[User:Thryduulf/sandbox]] is opened as [[User:Thryduulf/Bridgnorth Cliff Railway]]. A link to [[User:Thryduulf/sandbox2]] on the same page opens [[User:Thryduulf/User%3AThryduulf%2Fsandbox2]]. A link to that sandbox page
from a page in the article namespace opens as [[User%3AThryduulf%2Fsandbox2]], but this does get you to the correct page.

Elitre added a comment.Via ConduitAug 6 2013, 8:12 PM

Also reported today at it.wp (this was the result https://it.wikipedia.org/w/Tsonga_%28popolazione%29 ). Thanks.

Thryduulf added a comment.Via ConduitAug 25 2013, 3:39 PM
  • Bug 50466 has been marked as a duplicate of this bug. ***
Thryduulf added a comment.Via ConduitAug 28 2013, 7:39 PM
  • Bug 53491 has been marked as a duplicate of this bug. ***
matmarex added a comment.Via ConduitAug 28 2013, 10:04 PM

Fun fact: this is the most often duped VE bug ever, and it's in the top 30 of most often duped open bugs on our entire bugzilla, alongside classics such as bug 738 or bug 156. https://bugzilla.wikimedia.org/duplicates.cgi

matmarex added a comment.Via ConduitAug 28 2013, 10:05 PM
  • Bug 53190 has been marked as a duplicate of this bug. ***
gerritbot added a comment.Via ConduitSep 26 2013, 2:14 AM

Change 86065 had a related patch set uploaded by Catrope:
Resolve rendered URLs according to the provided <base>

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

Catrope added a comment.Via ConduitSep 27 2013, 12:23 AM

(In reply to comment #13)

Change 86065 had a related patch set uploaded by Catrope:
Resolve rendered URLs according to the provided <base>

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

This addresses the most common symptoms of this bug. It fixes rendering of link targets for internal links (at least on initial rendering; the href attribute doesn't update correctly when the link is edited), and it fixes href and src attributes of things inside of generated content nodes (templates, mostly).

While the change in Gerrit fixes href/src attribute rendering for uneditable href/src attributes, we still have to do something for models that manage their own href/src and edit it, or generate it from another editable attribute.

ve.dm.LinkAnnotation, ve.dm.MWExternalLinkAnnotation: href attribute is edited directly; in practice MWExternalLinkAnnotation is a full URL and LinkAnnotation isn't used in the MW integration, but we should still fix them.

ve.dm.MWInternalLinkAnnotation: Generates href based on title attribute, which can be edited. Links that came directly from Parsoid now render correctly due to a hack (see bug 51487), but edited links don't render correctly.

ve.dm.ImageNode, ve.dm.MWInlineImageNode, ve.dm.MWBlockImageNode: src attribute is edited directly; in practice, the MW ones use full URLs (the user doesn't edit the src directly, and the UI widget gets full URLs from the API) and ImageNode isn't used in the MW integration, but we should still fix them.

ve.dm.MWCategoryMetaItem, ve.dm.MWLanguageMetaItem: these manage hrefs that can be edited, but they're never rendered and always absolute, so we don't really care

gerritbot added a comment.Via ConduitOct 21 2013, 7:23 PM

Change 90952 had a related patch set uploaded by Catrope:
Render resolved URLs for href and src attributes in CE

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

gerritbot added a comment.Via ConduitOct 28 2013, 6:32 PM

Change 86065 merged by jenkins-bot:
Resolve rendered URLs according to the provided <base>

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

gerritbot added a comment.Via ConduitOct 28 2013, 6:55 PM

Change 90952 merged by jenkins-bot:
Render resolved URLs for href and src attributes in CE

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

Mattflaschen removed a subscriber: Mattflaschen.Via WebDec 3 2014, 5:35 AM

Add Comment