#17323 closed task (blessed) (fixed)
Warning for out of date and insecure browsers
| Reported by: |
|
Owned by: |
|
|---|---|---|---|
| Milestone: | 3.2 | Priority: | normal |
| Severity: | normal | Version: | 3.2 |
| Component: | Administration | Keywords: | |
| Focuses: | Cc: |
Description
Since we're dropping support for IE6, we've decided to warn users of their out of date or insecure browsers. Browse Happy is getting a makeover so we can link to it again.
Nacin is building an API to add to .org that we can use to check browser versions. The plan is to offer a different notice based on how insecure their browser is. An IE6 or IE7 user would see something like:
Your version of Internet Explorer is insecure. WordPress recommends an update.
And someone using any other out of date browser should see something like:
Your version of Firefox is out of date. WordPress recommends an update.
Attachments (18)
Change History (57)
#2
follow-up:
↓ 5
@
13 years ago
Since IE6 is not only insecure, but now (well, as of 3.2) completely unsupported in Admin, would it make sense to have a message indicating this instead/as well? Perhaps an if (IE <= unsupported version) mention "Your Version of Internet Explorer is unsupported. WordPress recommends an update"
#4
@
13 years ago
@nacin pointed out that the sky may fall on your head in the first patch if $raw_response['body'] can't be unserialized. He recommended if ( ! $response || ! $response['upgrade'] ). I'm opting instead to return if ! $response BEFORE the transient is set since it doesn't make sense to set the transient to something invalid.
Additionally he suggested caching longer, so I increased it from 1 day to 1 week.
#5
in reply to:
↑ 2
;
follow-up:
↓ 6
@
13 years ago
Replying to DH-Shredder:
Perhaps an if (IE <= unsupported version) mention "Your Version of Internet Explorer is unsupported. WordPress recommends an update"
I personally think that two warning messages are enough (insecure and outdated). Not to mention that we don't have to parse any user-agent stuff in WP for this because the API on .org will be supplying us with what we need. If we want to add an additional message like that we'll need to parse the user agent again to see what browser version the person is currently on (or modify the API to return more data).
#6
in reply to:
↑ 5
@
13 years ago
Replying to aaroncampbell:
I personally think that two warning messages are enough (insecure and outdated). <snip>
That makes sense -- that said, since we might want to make older versions of other browsers marked incompatible at some point, it could be a universal "incompatible" message (rather than Internet Explorer specific) -- i.e. "Your browser in incompatible with the Admin interface".
Totally understand the desire to limit the parsing -- just wanted to pass on the suggestion, since I see the potential for future use (especially if this is something that needs to be done at the API level).
#7
@
13 years ago
In so far as I know, the bulk of IE6 users are users who need it because of an old intranet app. As much as they'd like to upgrade, they can't do anything about it unless their system admin installs an alternative browser.
A smaller group includes users who have a very old desktop, and who probably aren't savvy enough to install a new browser irrespective of what we tell them to do.
Third-world countries arguably have an additional group, which is users with a very old and un-updatable pirated copy of WinXP...
Are we sure there's any point in adding a nag or a warning? (To me it seems kind of useless.)
#8
@
13 years ago
Adding to the previous comment, it is worth noting that some corporation refuse to install anything but IE6, precisely because many sites on which employees might potentially waste their time (facebook, twitter, gmail...) do not work with it.
#9
follow-up:
↓ 10
@
13 years ago
Yes I definitely think it's worth adding. Jane and I still need to meet on how it will look, but it's not going to be an "in your face" kind of thing. My thoughts are a text link in the footer of admin with the warning.
Also, I don't see any of the reasons you mention as very valid. I know there *are* apps that only work with IE6, but that's absolutely ridiculous at this point. It's time to move on. You do NOT want your users browsing the web on IE 6. If you have WordPress on an itranet that you deem safe for IE6, then one line of code would remove the nag:
remove_action( 'admin_footer', 'browser_upgrade_nag' );
Also, this is for less extreme cases as well. It would tell someone on Firefox 3.6 that they should probably upgrade. All in all I think it's refreshing to see users being nudged in the right direction.
#10
in reply to:
↑ 9
@
13 years ago
Replying to aaroncampbell:
Also, I don't see any of the reasons you mention as very valid. I know there *are* apps that only work with IE6, but that's absolutely ridiculous at this point. It's time to move on. You do NOT want your users browsing the web on IE 6.
I think you completely missed my point. I for one, as a business owner, completely understand the idea of installing XP with IE6 to avoid that employees use Facebook, Twitter, Gmail, etc. during work hours. I wouldn't do it myself, mind you. But I make perfect sense of why anyone would want to do so. Employees are just not supposed to be surfing during work hours. And no amount of nagging will make whoever is ultimately in charge of taking the final decision change his mind.
The nag you're suggesting will be visible to end-users, rather than the relevant decision makers. End-users sure as hell know that they're not supposed to be using IE6 already; there's no point in reminding them. Heck, keep in mind that even MS is waging war against IE6.
In my view, the only thing that officially dropping IE6 support will achieve, is to make a huge bunch of bosses happy: it'll be one more time-wasting app that employees won't be able to use. And I'm honestly fine with that.
In that sense, however, I beg to ask if any kind of IE6 nag anything useful.
I ultimately don't care myself, since I don't use the latter. But it strikes me that this ticket got opened without consulting with IE6 users. Put another way, might there be room for a "Why are you using IE6?" survey (maybe Automattic could do this as an additional question at the end of each poll from polldaddy for a few weeks and make the results public?), before we proceed with adding a nag?
If such a survey reveals that some 2% of users are lazy (the figure comes from MS's stats on the topic), fine: nag at will. But if they can do nothing about it, I honestly see no point.
#11
@
13 years ago
Well, I'm with you in that I see no downside to making bosses happy. Additionally, nag or no nag IE6 is no longer supported by WordPress. We might as well let the users know why what they're seeing may be wonky. Also, we're going to put the notice up for ALL out of date browsers (Firefox 3.6, Opera 10, Safari 4, etc) so I don't see any reason NOT to put the notice up for IE 6 users.
Anyway, it's been discussed at the last several dev chats and pretty much everyone seemed on board. At this point it's officially a blessed task.
#12
@
13 years ago
- Keywords ux-feedback added
http://api.wordpress.org/core/browse-happy/1.0/ now works based on UA-parsing code from Aaron and the help of Otto. Thanks!
Only thing we're waiting on is a determination of when and how to warn. The API could potentially become simpler if it is ultimately decided to not show a message for older browsers other than IE6/7, but per the IRC discussion, that is what the code so far has been written for.
So we need to figure out exactly what messages to show, including the specific text.
#14
@
13 years ago
The newest patch (17323.5.diff) does NOT remove the collapsing bits, uses the new functionality westi added to add a class to the metabox if the browser is "insecure", updates the styles accordingly, moves the new wp_check_browser_version() into wp-admin/include/dashboard.php, adds a dismiss link that actually works (thanks azzaoz).
Known issues:
- If you have too many columns or make your browser skinny enough, the browser logo can slightly overlap the metabox title.
- The sprite is really heavy (200k) and needs to be optimized.
#15
@
13 years ago
.6 no longer uses the sprite. Instead it uses img_src, another item provided by the API (images will be hotlinked to s.wordpress.org). It also escapes data from the API before displaying it, adds a link to the browser image and to the browser name in the first paragraph, and updates some of the comments regarding the API.
#17
@
13 years ago
The API now also returns img_src_ssl for SSL connections, so that block of code with the is_ssl() check needs to change slightly. Otherwise looks good for a first pass.
@
13 years ago
Fixes the ssl image src and also passes $response to the 'browse-happy-notice' filter
#18
@
13 years ago
- Owner set to azaozz
- Resolution set to fixed
- Status changed from new to closed
In [17887]:
#20
@
13 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
After this was committed I am getting this error in trunk:
WordPress database error: [Data too long for column 'option_name' at row 1]
INSERT INTO `wp_options` (`option_name`, `option_value`, `autoload`) VALUES ('_site_transient_timeout_browsehappy_64720d6ea3deca8475bf698a243e3c29', '1305778596', 'yes') ON DUPLICATE KEY UPDATE `option_name` = VALUES(`option_name`), `option_value` = VALUES(`option_value`), `autoload` = VALUES(`autoload`)
as a result of the issue raised in #15058. Either that needs to be fixed or the browsehappy transient needs a shorter string length?
#24
follow-up:
↓ 25
@
13 years ago
Added the screen-shot for informational purposes how it looks like after upgrade. Probably this should be checked prior upgrade ... :)
#25
in reply to:
↑ 24
@
13 years ago
Replying to hakre:
Added the screen-shot for informational purposes how it looks like after upgrade. Probably this should be checked prior upgrade ... :)
Honestly, the browser nag metabox doesn't look that bad. The rest of the dashboard does, but it doesn't support IE6, so I guess it's ok.
#27
@
13 years ago
Not sure if this nag alert feature is considered finished yet, but I think it needs more work.
On my BlackBerry PlayBook, when I log into my WP 3.2 test site, I get a warning to upgrade to the next version of Safari. Obviously, I can't do that, since I'm not even running Safari in the first place.
A lot of people use Research in Motion (RIM) devices, whether BlackBerry smartphones or the new PlayBook. Those folks shouldn't be seeing a message telling them to upgrade Safari. Is it possible to build in support for RIM's WebKit-based browser in the code that does the browser detecting?
Here's the User-Agent string a typical PlayBook would report:
Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US) AppleWebKit/534.8+ (KHTML, like Gecko) Version /0.0.1 Safari/534.8+
#28
follow-up:
↓ 29
@
13 years ago
- Resolution fixed deleted
- Status changed from closed to reopened
We need to check platforms on the API endpoint.
#29
in reply to:
↑ 28
@
13 years ago
Replying to nacin:
We need to check platforms on the API endpoint.
Yeah. I think you get similar issues if you browser the admin from an iphone/ipad too.
#30
@
13 years ago
Sorry guys, I don't have an ipad, iphone, or Blackberry. I did test with a bunch of different user-agent strings using User Agent Switcher a Firefox addon (which I imported a LOT of user agents into).
It still have my test API up which you can use to give me specific User Agents that aren't working and I'll try to fix things up.
http://xavisys.com/core/browse-happy/1.0/ Will give you info on the browser you are currently using
http://xavisys.com/core/browse-happy/1.0/?useragent=_ will let you specify a different user-agent string to test
However, When I put the PlayBook user agent from above in I get this:
"Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US) AppleWebKit/534.8+ (KHTML, like Gecko) Version /0.0.1 Safari/534.8+"
array(5) {
["insecure"]=>
bool(false)
["name"]=>
string(6) "webkit"
["version"]=>
string(5) "534.8"
["current_version"]=>
string(0) ""
["upgrade"]=>
bool(false)
}
Which says that the browsers does not need an upgrade and is not insecure. The live API gave me similar results
I also tested with iPhone and iPad strings and got the same expected result (no upgrade needed):
Mozilla/5.0 (iPhone; U; CPU iPhone OS 4_2_1 like Mac OS X; da-dk) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8C148 Safari/6533.18.5
Mozilla/5.0 (iPad; U; CPU OS 4_3 like Mac OS X; en-us) AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8F190 Safari/6533.18.5
Mozilla/5.0 (iPod; U; CPU iPhone OS 3_1_1 like Mac OS X; en-us) AppleWebKit/528.18 (KHTML, like Gecko) Mobile/7C145
I'm sure there are browsers the API doesn't treat properly, but as far as I can tell it DOES work as expected with the iPhone, iPad, and PlayBook.
@
13 years ago
Screenshot of WordPress 3.2-bleeding on BlackBerry PlayBook with "Upgrade to Safari" browser warning
#31
follow-up:
↓ 32
@
13 years ago
I just created a brand new test installation from trunk, and then logged into it from my PlayBook. Sure enough, there was an orange "Your browser is out of date" message on the dashboard telling me to upgrade Safari.
I've attached a screenshot (URL obscured) so you can see what I am seeing.
I don't have an iPad or iPhone, so I can't test from those devices, but I'm happy to test from my PlayBook. It is very easy to take screenshots on the PlayBook (RIM did an incredible job with this tablet) so I can keep the visuals coming if you need 'em.
#32
in reply to:
↑ 31
@
13 years ago
- Keywords ux-feedback removed
For anyone having a browser that is reported incorrectly, please follow these steps:
- Go here: http://xavisys.com/core/browse-happy/1.0/
- Copy/paste the content of that page into a comment here
- Make sure to specify what the browser SHOULD be in the comment as well.
Sample:
I'm using ABC browser on XYZ platform, but I'm seeing this:
"Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1"
array(6) {
["insecure"]=>
bool(false)
["platform"]=>
string(7) "Windows"
["name"]=>
string(7) "Firefox"
["version"]=>
string(5) "4.0.1"
["current_version"]=>
string(5) "4.0.1"
["upgrade"]=>
bool(false)
}
#33
@
13 years ago
Done. Funny thing is, it's almost identical to what you posted above.
I am using the native BlackBerry PlayBook browser on said device, and seeing this:
"Mozilla/5.0 (PlayBook; U; RIM Tablet OS 1.0.0; en-US) AppleWebKit/534.8+ (KHTML, like Gecko) Version/0.0.1 Safari/534.8+"
array(5) {
["insecure"]=>
bool(false)
["name"]=>
string(6) "webkit"
["version"]=>
string(5) "0.0.1"
["current_version"]=>
string(0) ""
["upgrade"]=>
bool(false)
}
Posted from my PlayBook
#35
@
13 years ago
The API on WP.org is slightly different from Aaron's version, as it had a bug when detecting webkit-based browsers. I will pass along the code on WP.org back to Aaron for syncing reasons.
#36
@
13 years ago
- Resolution set to fixed
- Status changed from reopened to closed
Playbook is now accounted for. Thanks Aaron for the patch.
New tickets please for any other platform conflicts or issues with this.
For future reference, you can go here to test your current user agent and see what the API thinks you are: http://api.wordpress.org/core/browse-happy/1.0/test.php. Any future ticket should include the user agent and the output there.
Thanks!
Obviously since the API doesn't exist yet the patch doesn't work, but that's the basic idea.