[wp-trac] [WordPress Trac] #31687: Customizer: fix errors when embedded in a different origin

[WordPress Trac]

#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