Currently we don't -> lots of broken imagery in /w/index.php etc. entry points.
Version: unspecified
Severity: major
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=59196
Description
Description
Details
Details
- Reference
- bz48915
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | Catrope | T53487 VisualEditor: Get rid of dmRendering stuff in ce.MWInternalLinkAnnotation | |||
| Resolved | Catrope | T50915 VisualEditor: Respect Parsoid's <base> |
Event Timeline
Comment Actions
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?
Comment Actions
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.
Comment Actions
Also reported today at it.wp (this was the result https://it.wikipedia.org/w/Tsonga_%28popolazione%29 ). Thanks.
Comment Actions
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
Comment Actions
Change 86065 had a related patch set uploaded by Catrope:
Resolve rendered URLs according to the provided <base>
Comment Actions
(In reply to comment #13)
Change 86065 had a related patch set uploaded by Catrope:
Resolve rendered URLs according to the provided <base>
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
Comment Actions
Change 90952 had a related patch set uploaded by Catrope:
Render resolved URLs for href and src attributes in CE
Comment Actions
Change 86065 merged by jenkins-bot:
Resolve rendered URLs according to the provided <base>
Comment Actions
Change 90952 merged by jenkins-bot:
Render resolved URLs for href and src attributes in CE