Make WordPress Core

Opened 15 years ago

Closed 14 years ago

#14537 closed feature request (fixed)

Support Google Chrome Frame

Reported by: nacin's profile nacin Owned by: nacin's profile nacin
Milestone: 3.2 Priority: normal
Severity: normal Version:
Component: Administration Keywords: has-patch commit
Focuses: Cc:

Description

This was something that came out of the core development days after WordCamp SF, but I realized we never created a ticket for it: support Google Chrome Frame in the admin.

I think we should just add the meta tag, versus also prompting for installation, etc.

Attachments (9)

14537.patch (481 bytes) - added by hakre 14 years ago.
Google Chrome Frame support in Admin for Browsers that have Google Chrome Frame installed.
14537.2.patch (1.2 KB) - added by hakre 14 years ago.
Introducing $is_chromeframe
14954.patch (663 bytes) - added by hakre 14 years ago.
Google Chrome Support for Admin, introduces $is_chromeframe and deals with bug #14954
14537.3.patch (1.3 KB) - added by hakre 14 years ago.
Google Chrome Support for Admin, introduces $is_chromeframe and deals with bug #14954
gcf.diff (815 bytes) - added by nacin 14 years ago.
14537.gcf-admin-filter.patch (872 bytes) - added by hakre 14 years ago.
reworked gcf, no need for stripos for chromeframe.
14537.4.patch (1.3 KB) - added by hakre 14 years ago.
Filtered as in GCF lineup. Seperated Concerns.
14537.5.patch (946 bytes) - added by hakre 14 years ago.
Preserves $is_IE, Fixes #14954, has filter, seperates concerns.
14537.6.patch (1.2 KB) - added by hakre 14 years ago.
Preserves $is_IE, Fixes #14954, has filter, seperates concerns, introduces $is_chromeframe.

Download all attachments as: .zip

Change History (34)

#1 @hakre
15 years ago

Chrome Frame Guide

<meta http-equiv="X-UA-Compatible" content="IE=8,chrome=1">

That's not playing nicely with users even while IE sucks. What about a plugin to spare some bloat or is there actually any need to use Chrome Frame for something specific?

#2 @demetris
14 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

I suggest we forget about this, at least for now (even the simple META addition).

First, as far as I understand, GCF does not provide a seamless user experience.

Second, if users want to use the Chrome browser, they can install it. If they cannot install it (e.g., in work machines because of policy restrictions), very likely they won’t be able to isntall GCF either.

Third, if we start doing everything Google says, then, before long, the HEAD element will be larger than the BODY element itself. :-D

#3 @hakre
14 years ago

+1, especially for the part about the head :)

#4 @nacin
14 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

#5 @mrmist
14 years ago

The meta tag implementation of Google Frame is messy, and actually can be quite confusing. I didn't even realise it was installed until I visited a site with the meta tag and IE kept warning about external programs.

This should be a plugin or theme thing, I reckon. Then people can make an active choice to add it.

#6 @hakre
14 years ago

I would have already closed it as wontfix, even close being a duplicate as of #10880. so +1 for closing.

For those who are in a barely need for such a (in my eyes not core material) feature, there's now an execlusive plugin available in the scope of this ticket: Chrome Frame (WordPress Plugin)

#7 follow-up: @nacin
14 years ago

  • Owner set to nacin
  • Status changed from reopened to accepted

Google Chrome Frame is now out of beta. All we're advocating for is the meta tag. That means that we'll leverage Chrome Frame whenever someone has it installed, and otherwise no action will be taken. I'm not advocating we implement the scripts such as CFInstall that tell the user what is available to them.

If users do not want the feature, then they don't need to have Chrome Frame installed or enabled. But if they do, we should aim to deliver them the best possible experience. There is zero harm to this.

GCF announces itself in the HTTP_USER_AGENT so we will need to update wp-includes/vars.php. We can even only serve the header when the browser says it has GCF.

#8 in reply to: ↑ 7 @hakre
14 years ago

  • Resolution set to duplicate
  • Status changed from accepted to closed

Duplicate: #10880

@nacin no offence please, please re-open the original ticket and comment there.

#9 @nacin
14 years ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

That ticket also suggested a constant for wp_head -- here, we're going for something on admin_head. Regardless, this ticket is already slated as a blessed task on 3.1.

#10 @hakre
14 years ago

Add a http header like with the plugin then it stays compatible with implementations on the webserver layer as it is already suggested for admins regardless of some implementation in specific apps:

<IfModule mod_setenvif.c>
  <IfModule mod_headers.c>
    BrowserMatch chromeframe gcf
    Header append X-UA-Compatible "chrome=1" env=gcf
  </IfModule>
</IfModule>

The question is which version of browsers to support? All Browsers that have google Chrome installed or only specific vendors or even specific versions of specific browser vendors?

@hakre
14 years ago

Google Chrome Frame support in Admin for Browsers that have Google Chrome Frame installed.

#11 @hakre
14 years ago

  • Keywords has-patch added

NOTE: Any browser (but lynx) that has google chrome installed will be reported as being chrome currently. Related: #14954

@hakre
14 years ago

Introducing $is_chromeframe

#12 @nacin
14 years ago

  • Status changed from reopened to accepted

Accepting this and will handle #14537 here.

@hakre
14 years ago

Google Chrome Support for Admin, introduces $is_chromeframe and deals with bug #14954

@hakre
14 years ago

Google Chrome Support for Admin, introduces $is_chromeframe and deals with bug #14954

@nacin
14 years ago

@hakre
14 years ago

reworked gcf, no need for stripos for chromeframe.

#13 @hakre
14 years ago

GCF patches are interweaving the user-agent differentiation code with sending GCF headers. This is only adding complexity. I suggest to keep the two domains apart from each other.

Next to the the two GCF named patches have the problem that even with GCF installed, IE is still IE for everything HTTP as far as I can see in my server logs. So it's better to introduce and additional $is_chromeframe variable and to deal accordingly upon it w/o overriding $is_IE while GCF is installed on a client machine.

#14 @hakre
14 years ago

As noted in IRC (and here by mrmist) when the security settings prevent the launch of GCF, then the User is confronted with a error message and can't go on (no page will be loaded in one of the hardest scenarios).

This is because the patch forces GCF to be used blindly for any browser that has it installed (I do not see any option with GCF to white/blacklist sites we could refer to on the server side).

Strictly spoken, only because there is "chromeframe" in the User-Agent string, this must not mean that the user wants to use it for the host the blog is installed on.

@hakre
14 years ago

Filtered as in GCF lineup. Seperated Concerns.

@hakre
14 years ago

Preserves $is_IE, Fixes #14954, has filter, seperates concerns.

@hakre
14 years ago

Preserves $is_IE, Fixes #14954, has filter, seperates concerns, introduces $is_chromeframe.

#15 follow-up: @hakre
14 years ago

From a view out of the core, there is no need to preserve $is_IE as it is not used in core code. There is one (as of 3.0 deprecated) use of $is_winIE so it's highly likly no need to preserve as well.

#16 @hakre
14 years ago

GCF does not work on sites that prevent file downloads. In case you should run into problems after any of these patches applied to visit your blogs admin, you must enable file donwloads in your internet explorer.

#17 in reply to: ↑ 15 @demetris
14 years ago

Replying to hakre:

From a view out of the core, there is no need to preserve $is_IE as it is not used in core code. There is one (as of 3.0 deprecated) use of $is_winIE so it's highly likly no need to preserve as well.

$is_IE is used by quite a few themes. $is_winIE, I don’t know. Maybe there are also plugins using one or the other.

#18 @scribu
14 years ago

  • Type changed from task (blessed) to feature request

#19 @scribu
14 years ago

As Jane said, only lead devs should bless tasks.

#20 @westi
14 years ago

  • Milestone changed from 3.1 to Future Release

This is not for 3.1

#21 @nacin
14 years ago

  • Milestone changed from Future Release to 3.2

Moving to 3.2 for review, in light of IE6 EOL. Some will be forced due to corporate policy or the like to use IE6. gcf.diff is a simple solution to allow those who have GCF installed to actually leverage it.

If you do not have GCF installed, this doesn't affect you. If you have it installed, you have indicated a clear preference for GCF. I see no contraindications to applying this patch.

#22 follow-up: @westi
14 years ago

If we do this we should still show the IE6 browse happy nag as even with Chrome Frame available they are not protected.

#23 in reply to: ↑ 22 @nacin
14 years ago

  • Keywords commit added

Replying to westi:

If we do this we should still show the IE6 browse happy nag as even with Chrome Frame available they are not protected.

I've confirmed that the API will still detect IE rather than Chrome.

Marking for commit rather than actually committing as I don't have IE6 handy to be able to actually test IE + GCF.

#24 @ryan
14 years ago

gcf.diff works for me in IE6. The browse happy nag still shows.

#25 @ryan
14 years ago

  • Resolution set to fixed
  • Status changed from accepted to closed

In [18036]:

Support Chrome Frame. fixes #14537

Note: See TracTickets for help on using tickets.