https://bugzilla.wikimedia.org/show_bug.cgi?id=52486
Web browser: ---
Bug ID: 52486
Summary: VisualEditor: Copying of styles to dialog frame is
dirty
Product: VisualEditor
Version: unspecified
Hardware: All
OS: All
Status: NEW
Severity: normal
Priority: Unprioritized
Component: General
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Classification: Unclassified
Mobile Platform: ---
Created attachment 13054
--> https://bugzilla.wikimedia.org/attachment.cgi?id=13054&action=edit
Screenshot where it works (VE copied it from <style>)
When VE copies styles into the frame, in the case of copying from a friendly
<link> tag (e.g. one that is readable, we inspect it and copy the contents
over, as opposed to a foreign one we have to fetch again from the iframe).
In that case, the css we manage to extract from the remote <link> appears to be
dirty and neither strictly or effectively roundtrips. Both the actual css it
copied and the effective values are different.
For example, in the case of "background: none;" it gets dirtied to
"background-image: none; background-position: initial initial;
background-repeat: initial initial;". Which means it no longer overrides
background-color.
Now, in some browsers background: none (old IE iirc) is indeed interpreted as
the above, and it would be reasonable behaviour of it expands it to what it
interprets it as.
However in the case of Chrome, it does't just normalise but actually gives us
values that don't match. See attached screenshots.
The side effects (e.g. broken styles) are currently (e.g. MediaWiki context)
most visible in debug mode because then almost everything is loaded through
<link> and as such subject to this bug. In production mode most things are
loaded by ResourceLoader and thus evaluated inline. However it is a bug both in
production as well, it is just a matter of time before we find random broken
styles.
- Figure out if we can get the contents without normalisation
- Perhaps fallback indefinitely to always using <link href> for remote
stylesheets, thus costing a few extra http requests inside the dialog, but that
might be the only way we can for now.
- Figure out how many things are affected and in which browsers. Maybe we can
get it fixed upstream reasonably fast (these seem to be genuine bugs in the
browser).
- If there's only a few properties subject to dirty normalisation, we could
consider changing our stylesheets to avoid those properties. E.g. instead of
background: none; use background-color: none; (something less ambiguous, and
probably correct in this case, though it is a bug still because it works in
Chrome normally, but not after roundtripping to an iframe).
--
You are receiving this mail because:
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
