[wp-trac] [WordPress Trac] #31687: Customizer: fix errors when embedded in a different origin
WordPress Trac
noreply at wordpress.org
Wed Mar 18 20:35:09 UTC 2015
#31687: Customizer: fix errors when embedded in a different origin
--------------------------+-----------------------------
Reporter: mattwiebe | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Customize | Version: 4.1
Severity: normal | Keywords:
Focuses: javascript |
--------------------------+-----------------------------
Changes introduced during the 4.1 cycle create errors when the Customizer
is embedded (via iframe) in an origin other than wp-admin. On
WordPress.com, we use
`https://wordpress.com/customize/yourblogname.wordpress.com` as the route
into loading the Customizer in an iframe. This worked fine with the stock
Customizer before 4.1 but two changes were needed as of 4.1.
In `customize-base.js`, using `_.isEqual()` in `api.Value::set` produces
a `SecurityError`, traced back to setting `self.targetWindow` in
`customize-controls.js`, since `_.isEqual()`, when checking for equality,
attempts to access an object's prototype chain. The blank window object in
the iframe (foo.wordpress.com/wp-admin/customize.php) takes on the origin
of the parent context (wordpress.com) and attempting to access any object
properties produced a fatal `SecurityError`, crippling the app and
preventing it from loading. The try/catch pattern in the attached patch
isn't pretty, but it works.
In `customize-controls.js`, the attempt to set the parent's
`document.title` likewise produced a `SecurityError`, but this one at
least doesn't cripple the Customizer, it just litters the console with
`SecurityError`s. Again, try/catch can take care of this.
The patch we're using to alleviate these issues on wp.com is attached.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/31687>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list