Opened 15 years ago
Closed 14 years ago
#14537 closed feature request (fixed)
Support Google Chrome Frame
Reported by: |
|
Owned by: |
|
---|---|---|---|
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)
Change History (34)
#2
@
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
#5
@
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
@
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:
↓ 8
@
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
@
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
@
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
@
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?
@
14 years ago
Google Chrome Frame support in Admin for Browsers that have Google Chrome Frame installed.
#11
@
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
#12
@
14 years ago
- Status changed from reopened to accepted
Accepting this and will handle #14537 here.
@
14 years ago
Google Chrome Support for Admin, introduces $is_chromeframe and deals with bug #14954
@
14 years ago
Google Chrome Support for Admin, introduces $is_chromeframe and deals with bug #14954
#13
@
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
@
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.
@
14 years ago
Preserves $is_IE, Fixes #14954, has filter, seperates concerns, introduces $is_chromeframe.
#15
follow-up:
↓ 17
@
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
@
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
@
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.
#21
@
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:
↓ 23
@
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
@
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.
Chrome Frame Guide
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?