Opened 12 years ago
Closed 12 years ago
#22446 closed defect (bug) (fixed)
Insert Media modal: IE 7, 8, and 9 issues
Reported by: | SergeyBiryukov | Owned by: | ocean90 |
---|---|---|---|
Milestone: | 3.5 | Priority: | normal |
Severity: | normal | Version: | 3.5 |
Component: | Media | Keywords: | audit has-patch commit |
Focuses: | Cc: |
Description (last modified by )
The vertical line on the left is displayed in IE 9, but not in IE 8 (see 22446.ie8.png, 22446.ie9.png).[22610]
"Drop files anywhere to upload" shouldn't be displayed in IE 7/8/9, as it doesn't support drag-and-drop (at least it doesn't on[22609]wp-admin/media-new.php
).
- IE 7 needs some attention for the gallery view, see 22446.ie7_gallery.png
- IE 7 doesn't display the selected images (22446.ie7_selected_images.png)
and in IE 9 you can see the second line (22446.ie9_selected_images.png)[22876]
In IE 7 and IE 8 you can't see which image is currently selected (blue border is missing), see 22446.ie8_selected_image.png.The check mark has been improved. Should be enough.
- In IE 7 Embed from URL doesn't work. Nothing happens after inserting an URL.
When uploading an image in IE 7 ( and IE 8?) a pop up comes up which wants to download[22845]admin-ajax.php
. The file includes the JSON respond.
IE 8: Upload an image, switch to media library, try to change the filter dropdown. It will open the upload dialog.[22781]
IE 8, 9, 10: Non-image thumbnails are quite off, see 22446.ie9.selected-music.png or 22446.ie9.selected-music2.png.[22876]
IE 7, 8, 9, 10: Images are inserted only at the beginning/top of the content in TinyMCE. 22446-ie789-insert.patch[22877]
Attachments (23)
Change History (77)
#1
@
12 years ago
- Description modified (diff)
- Summary changed from Insert Media modal looks odd in IE 8 to Insert Media modal: IE 7, 8, and 9 issues
#4
@
12 years ago
- Keywords needs-patch added
- Owner set to ocean90
- Status changed from new to accepted
#15
@
12 years ago
Priority 1: IE9 and IE8.
Priority 10: IE7. If we just hide this feature for IE7, I won't complain. We need to spend time on making sure that IE9 and IE8 work. Until they have no bugs, IE7 shouldn't be touched.
#16
@
12 years ago
In IE8 When I upload an image (by clicking "Select files"), I see the following: http://cl.ly/image/2X392f3O2c3l (tested locally and on my MediaTemple server).
#18
follow-up:
↓ 20
@
12 years ago
RE: comment:16:
MarkJaquith got on Skype and helped me figure out a fix for this. In wp-includes/functions.php line 2276 if you replace:
@header( 'Content-Type: application/json; charset=' . get_option( 'blog_charset' ) );
with:
@header( 'Content-Type: text/html;' );
The issue is resolved for me. Can we do this conditionally for IE7 & IE8?
#19
@
12 years ago
I forgot about this. Older versions of IE don't like application/json and should instead receive text/plain (I think, over text/html). Not sure if there are workarounds beyond browser detection or always serving text/*.
I seem to recall there being an explicit JS-based, koop-ordered reason for delivering application/json instead of text/html here. He will know if text/plain would be okay instead.
#20
in reply to:
↑ 18
@
12 years ago
Replying to lessbloat:
... Can we do this conditionally for IE7 & IE8?
Not just IE7 and 8, IE9 doesn't understand application/json either.
#21
follow-up:
↓ 22
@
12 years ago
We're using application/json
so jQuery's ajax method automatically parses the JSON. It also accepts text/javascript
, which sounds like a viable IE fallback. I'd like to see a patch that sniffs for IE and replies with text/javascript
instead.
If that doesn't work, we can overload it client-side to make sure that takes place, but then our shiny new ajax functions lose a bit of their luster.
#22
in reply to:
↑ 21
;
follow-up:
↓ 23
@
12 years ago
Replying to koopersmith:
I'd like to see a patch that sniffs for IE and replies with
text/javascript
instead.
Unfortunately IE doesn't recognize text/javascript
either. Only text/html
.
Would that patch be:
if ( $is_IE ) @header( 'Content-Type: text/html;' ); else @header( 'Content-Type: application/json; charset=' . get_option( 'blog_charset' ) );
#23
in reply to:
↑ 22
@
12 years ago
Replying to azaozz:
Would that patch be:
if ( $is_IE ) @header( 'Content-Type: text/html;' ); else @header( 'Content-Type: application/json; charset=' . get_option( 'blog_charset' ) );
$is_IE didn't appear to be set (or accessible), I borrowed most of your code for 22446-download-ajax.diff which fixes this issue for me in IE8.
Note: IE7 continues to output errors when attempting to upload an image. Could be issues in addition to the Content-Type declaration.
#24
@
12 years ago
The fact that all of the other XHR requests are performing correctly means that jQuery is handling the current code correctly — the error here is with plupload. And understandably so, as it is juggling numerous transports.
Instead of using the new wp_send_json_*
methods (which we already had to manually parse), we should just use the traditional method of echoing some json and calling wp_die()
in wp_ajax_upload_attachment()
.
Attaching a patch to do just that.
#29
@
12 years ago
All I see left is:
- Non-image thumbnails are off in IE8-10
- Everything else is IE7 only
If that is accurate, I'd like to close this ticket out, and have a single IE7 ticket, and individual tickets for anything else that comes up.
#30
@
12 years ago
Not sure if that's new but images are inserted only at the beginning/top of the content in MCE in all IE7-8-9. Looking at this now.
#31
@
12 years ago
22446-ie789-insert.patch saves a bookmark of the caret position in TinyMCE (only needed for IE) that is restored later, before inserting content/using send_to_editor().
#32
@
12 years ago
- Description modified (diff)
Adding azaozz's bug and patch to the end here.
Let's aim to polish off items 9 and 10 ASAP, then close this ticket and spin the IE7 stuff off.
#34
follow-ups:
↓ 35
↓ 36
@
12 years ago
I'm not really sure the best place to stick this code, but 22446-icon-placement.diff is an attempt to fix item 9.
#35
in reply to:
↑ 34
@
12 years ago
Replying to lessbloat:
I'm not really sure the best place to stick this code, but 22446-icon-placement.diff is an attempt to fix item 9.
I thought IE 10 doesn't support conditional comments anymore.
#36
in reply to:
↑ 34
;
follow-up:
↓ 37
@
12 years ago
Replying to lessbloat:
I'm not really sure the best place to stick this code
We could probably add ie9
class to <html>
element in _wp_admin_html_begin()
, like we do for IE 8.
Looks like IE 10 indeed doesn't support conditional comments. Perhaps we could use JS feature detection (as suggested in the related thread on Stack Overflow) to add ie10
class to <html>
.
The CSS would then go to media-views.css
.
#37
in reply to:
↑ 36
;
follow-up:
↓ 38
@
12 years ago
Replying to SergeyBiryukov:
Replying to lessbloat:
I'm not really sure the best place to stick this code
We could probably add
ie9
class to<html>
element in_wp_admin_html_begin()
, like we do for IE 8.
Looks like IE 10 indeed doesn't support conditional comments. Perhaps we could use JS feature detection (as suggested in the related thread on Stack Overflow) to add
ie10
class to<html>
.
The CSS would then go to
media-views.css
.
Something like 22446-icon-placement-v2.diff?
#38
in reply to:
↑ 37
@
12 years ago
Replying to lessbloat:
Something like 22446-icon-placement-v2.diff?
Yeah. is_ie_browser()
seems unnecessary though, we could just append the class to $admin_html_class
.
#39
@
12 years ago
22446-hide-second-line.diff looks to fix the ie9 issue in item 4. It doesn't appear to adversely affect other browsers.
#40
@
12 years ago
22446-icon-placement-v3.diff
looks good, but _wp_admin_html_begin()
isn't used on front end. We should try to add it directly to the modal.
#41
@
12 years ago
22446-icon-placement-v3.diff has a stray [endif]
in line 1649.
#43
follow-up:
↓ 44
@
12 years ago
If we don't *need* .ie10 in the admin, it would be nice to stick to conditional comments for .ie8 in the admin (we can add .ie9 the same way if we ever need it), and then only apply this to the modal.
#44
in reply to:
↑ 43
@
12 years ago
Replying to nacin:
If we don't *need* .ie10 in the admin, it would be nice to stick to conditional comments for .ie8 in the admin (we can add .ie9 the same way if we ever need it), and then only apply this to the modal.
22446-icon-placement-v6.diff should do the trick without needing to mess with conditionals. Tested in IE8, IE9 (on win), and FF, Chrome (on Mac). Needs further testing.
#46
@
12 years ago
- Keywords has-patch commit added; needs-patch removed
Results of 22446-icon-placement-v7.diff
: Works in Chrome, Firefox, Safari, Opera, IE 8, IE 9, IE 10.
22446-hide-second-line.diff
: It should be reduced to 48px. Tested in the same browser as above.
#49
@
12 years ago
Assigning 22446-ie789-insert2.patch to koopersmith for a quick review.
I opened #22609 to cover IE7 issues. After 22446-ie789-insert2.patch, this can be closed as fixed.
New tickets for all new issues, please. (IE7-only issues can go to #22609.)
The missing borders around the images are a result of the use of
box-shadow
, which IE 7 and 8 doesn't support. I think we should try to use real CSS borders here.