Opened 14 years ago
Closed 11 years ago
#20148 closed enhancement (worksforme)
Preview post in Webkit browser doesn't render Flash objects
| Reported by: | thomasvanderbeek | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | General | Version: | 3.3.1 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
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)
#2
@
14 years ago
- Summary Preview post in Chrome (Mac OS) doesn't render Flash objects → Preview post in Chrome doesn't render Flash objects
#4
@
14 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&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&hl=en_US" type="application/x-shockwave-flash" width="420" height="315" allowscriptaccess="always" allowfullscreen="true"></embed></object>
#5
@
14 years ago
Thx.
The log gives me: Refused to execute a JavaScript script. Source code of script found within request.
#6
@
14 years ago
- Keywords dev-feedback removed
- Summary Preview post in Chrome doesn't render Flash objects → Preview post in Webkit browser doesn't render Flash objects
Safari/Webkit too.
See:
#7
@
14 years ago
- Type defect (bug) → 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.
#9
@
14 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.
#10
@
14 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.
#11
@
14 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.
#12
@
14 years ago
I expect the header needs to be included on the preview page itself, not on the response with the redirect.
#13
@
14 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_filter( 'wp_headers', 'send_no_xss_protection_header', 10, 2 );
![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png)
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.