Last modified: 2014-11-04 00:56:34 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T54486, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 52486 - VisualEditor: Copying of styles to dialog frame is dirty
VisualEditor: Copying of styles to dialog frame is dirty
Status: RESOLVED FIXED
Product: VisualEditor
Classification: Unclassified
Technical Debt (Other open bugs)
unspecified
All All
: Low enhancement
: VE-deploy-2014-11-05 (1.25wmf7)
Assigned To: Roan Kattouw
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-08-02 23:46 UTC by Krinkle
Modified: 2014-11-04 00:56 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Screenshot where it works (VE copied it from <style>) (210.59 KB, image/png)
2013-08-02 23:46 UTC, Krinkle
Details
Screenshot where it is dirty and broken (VE copied it from <link>) (221.25 KB, image/png)
2013-08-02 23:46 UTC, Krinkle
Details

Description Krinkle 2013-08-02 23:46:22 UTC
Created attachment 13054 [details]
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).
Comment 1 Krinkle 2013-08-02 23:46:44 UTC
Created attachment 13055 [details]
Screenshot where it is dirty and broken (VE copied it from <link>)
Comment 2 Krinkle 2013-08-02 23:50:16 UTC
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
Comment 3 James Forrester 2014-11-04 00:56:34 UTC
Effectively fixed for dialogs by expedient of not doing this any more…

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links