Page MenuHomePhabricator

VisualEditor: Copying of styles to dialog frame is dirty
Closed, ResolvedPublic


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).

Version: unspecified
Severity: enhancement


Screen_Shot_2013-08-03_at_1.35.37_AM.png (1×1 px, 210 KB)



Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 1:48 AM
bzimport set Reference to bz52486.

Created attachment 13055
Screenshot where it is dirty and broken (VE copied it from <link>)


Screen_Shot_2013-08-03_at_1.36.34_AM.png (1×1 px, 221 KB)

Has the bug:

  • Chrome 29 beta
  • Chrome 30 canary
  • Safari 6.0.5

Does not have the bug:

  • Firefox 22 stable
  • Firefox Aurora 24.0a2

Effectively fixed for dialogs by expedient of not doing this any more…