WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 months ago

#20148 closed enhancement (worksforme)

Preview post in Webkit browser doesn't render Flash objects

Reported by: thomasvanderbeek Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.3.1
Component: General Keywords:
Focuses: Cc:

Description

When inserting a Flash <object> via HTML and use Preview function in Chrome it doesn't show.

  • Tested on a clean WordPress 3.3.1 install, no plugins activated, theme: twentyeleven.
  • The <object> code is available in the sourcecode. It just doesn't render... When you hit refresh it shows.
  • Tried this on multiple work stations (Windows and Mac os). All versions of Chrome.
  • Only in Chrome. Firefox has no issues with this function.
  • There is no difference between Multisite or Single site installations.
  • I'm Administrator (or Network administrator) in all cases.

Issue is also on WordPress support forums: http://wordpress.org/support/topic/preview-post-in-chrome-mac-os-doesnt-generate-flash-objects

Change History (18)

comment:1 @CoenJacobs3 years ago

  • Cc coenjacobs@… added

Tried this in a blank WordPress install too, problem occurs in Chrome only. Is there something that conflicts with the Webkit engine? Funniest part is that after a refresh it does show the embed. The source code of the page is the exact same in both cases; before and after the refresh.

comment:2 @thomasvanderbeek3 years ago

  • Summary changed from Preview post in Chrome (Mac OS) doesn't render Flash objects to Preview post in Chrome doesn't render Flash objects

comment:3 @ocean903 years ago

Could you please provide some <object> code?

comment:4 @CoenJacobs3 years ago

I've used an old embed code from a (not so random :) ) YouTube video:

<object width="420" height="315"><param name="movie" value="http://www.youtube.com/v/dQw4w9WgXcQ?version=3&amp;hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/dQw4w9WgXcQ?version=3&amp;hl=en_US" type="application/x-shockwave-flash" width="420" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>

comment:5 @ocean903 years ago

Thx.

The log gives me: Refused to execute a JavaScript script. Source code of script found within request.

comment:6 @ocean903 years ago

  • Keywords dev-feedback removed
  • Summary changed from Preview post in Chrome doesn't render Flash objects to Preview post in Webkit browser doesn't render Flash objects

comment:7 @CoenJacobs3 years ago

  • Type changed from defect (bug) to enhancement

Was afraid we would stumble on something like this.

With Webkit doing this, isn't it likely any other browser engine will also start refusing scripts in HTTP requests? I think it is a valid feature request to think of another way to make the preview work.

comment:8 @johnbillion3 years ago

  • Cc johnbillion added

comment:9 @johnbillion3 years ago

Is there even a way around this? The embed code has to be present in the POST request and it has to be returned in the response for the preview. I wouldn't be surprised if the same code present in the response to a redirect after the POST also gets blocked, but I haven't tried it.

comment:10 @johnbillion3 years ago

Ok there's an X-XSS-Protection header available for controlling the protection (if you can call it that). Protection will be disabled with a value of 0 in the header. Maybe we could output that header in post previews.

comment:11 @ocean903 years ago

johnbillion, I've just tried this.

In wp-admin/includes/post.php

case 'preview':
	check_admin_referer( 'autosave', 'autosavenonce' );

	$url = post_preview();

	header( "X-XSS-Protection: 0", true );
	wp_redirect($url);
	exit();
	break;

Header will be sent, but message is still there.

comment:12 @johnbillion3 years ago

I expect the header needs to be included on the preview page itself, not on the response with the redirect.

comment:13 @ocean903 years ago

Yeah, you are right, this works for me:

function send_no_xss_protection_header( $headers, $object ) {
	if ( ! empty( $object->query_vars['preview'] ) )
		$headers['X-XSS-Protection'] = 0;

	return $headers;
}
add_action( 'wp_headers', 'send_no_xss_protection_header', 10, 2 );
Version 0, edited 3 years ago by ocean90 (next)

comment:14 @vegasgeek3 years ago

  • Cc john@… added

As a side note, I clicked preview in Chrome and the embed didn't show up. But, hitting refresh on the browser for the preview page caused the embed to show up.

comment:15 @ocean903 years ago

Duplicate: #21047

comment:16 @toscho3 years ago

  • Cc info@… added

comment:17 @ocean902 years ago

#23437 was marked as a duplicate.

comment:18 @chriscct73 months ago

  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed

The sample object provided in comment:4 works in Chrome 42.0.2311.135. Looks like Chrome fixed this at some point. Closing as worksforme

Note: See TracTickets for help on using tickets.