chromeframe not always present in the user-agent

[Paul Carey]

Hi

If my server detects a user is running IE6 and not running chromeframe
it directs them to /ie6 where they're prompted to install chromeframe.

The chromeframe works once installed, but the user-agent appears to
omit chromeframe when the page from which it was installed is
requested.

216.37.72.238 - - [28/Oct/2009:18:34:15 +0000] "GET / HTTP/1.1" 302
2832 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)
chromeframe/4.0"
216.37.72.238 - - [28/Oct/2009:18:34:33 +0000] "GET /ie6 HTTP/1.1" 200
1608 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"

This means my install process simply returns the user to the page
where they're prompted to install chromeframe.

I'm testing via a virtualized XP SP2 instance on
crossbrowsertesting.com so I guess it's possible caching might be to
blame. Any thoughts?

Many thanks

Paul

[Andrea Giammarchi]

Are you sure the content of the page is not simply cached?

This is a test page where you can see server sent userAgent and client side user agent.
Test with and without cf: as prefix to see how different are user agents:
http://www.3site.eu/chromeframe/userAgent.php

The important thing is that in the server userAgent should always contain "chromeframe" if it has been installed.
Please try with your virtual XP2 configuration and tell me if you always read chromeframe in the top line (the second one should have WebKit if you call via cf:)

Regards

[Tommi]

How and when the user agent is modified did change in this version.  The user agent is not tagged for requests for embedded content but should be tagged for all top level requests and requests issued from script.

Are you seeing this for a top level page?  Caching could also be the reason, but since the user agent did change so better to be sure.

Tommi

[Andrea Giammarchi]

Sorry Tommi,
are you saying that now userAgent is sent as the WebKit/Chrome one if there is a cf prefix?

AFAIK the sent userAgent with or without cf prefix should always be the original one with "chromeframe" keyword.

Anyway, you are right about the top level window and internals so I have updated precedent test page with an iframe.

Regards

[Paul Carey]

> Are you sure the content of the page is not simply cached?

Well, I see the entry in my server logs, but it's possible that
caching is being performed by an intermediary - I simply don't know.

> Please try with your virtual XP2 configuration and tell me if you always
> read chromeframe in the top line (the second one should have WebKit if you
> call via cf:)

Yes. The only time chromeframe isn't present is when I request the url
from which it was originally installed.

Paul

[Paul Carey]

> Are you seeing this for a top level page?  Caching could also be the reason,
> but since the user agent did change so better to be sure.

A top level page, as in, when I enter a url in the address bar and hit
return / click go? Yes, this is what I was doing when chromfrome
wasn't present (the request at 18:34:33 in the server logs above).
Sadly, I don't have anything more to go on right now.

Paul

[Tommi]

On Thu, Oct 29, 2009 at 3:40 AM, Andrea Giammarchi <andrea.g...@gmail.com> wrote:

Sorry Tommi,
are you saying that now userAgent is sent as the WebKit/Chrome one if there is a cf prefix?

AFAIK the sent userAgent with or without cf prefix should always be the original one with "chromeframe" keyword.

In the latest dev release, it's "chromeframe/4.0" and  it's tagged at the end of the user agent header and not in the product/comment section of IE's header.  Furtheremore it's not always sent, but it should be sent for all top level requests and script requests.  E.g. you won't see it in requests for embedded images.

Another change that was made (and requested in this forum) is that if the CF BHO is disabled, the user agent will not include chromeframe at all. 

[Andrea Giammarchi]

Hi Tommi, thanks for answering.
It's weird cause I should have installed the dev version but apparently things are the same.

Moreover:

On Thu, Oct 29, 2009 at 4:19 PM, Tommi <to...@chromium.org> wrote:

Furtheremore it's not always sent, but it should be sent for all top level requests and script requests.  E.g. you won't see it in requests for embedded images.

I may have missed the related post but why this choice? If I have IE6 without png suport and I require an image with ChromeFrame enabled I would like to obtain a png rather than a jpeg or gif, am I wrong?

<img src="whatever.image" width="320" height="60" />

and in whatever.image

header('image/'.(strpos('chromeframe', $_SERVER['HTTP_USER_AGENT']) !== false ? 'png' : 'jpeg'));

I agree that via server is not possible to understand if the user is running in chromeframe mode but at the same time if there is a check like that means we have activated before chromeframe in the page or we would like to use it ... am I missing something here?

 

Another change that was made (and requested in this forum) is that if the CF BHO is disabled, the user agent will not include chromeframe at all. 

Yes, this makes much more sense but I can't get the other choice.

Regards

[Tommi]

Hey Andrea,

The decision wasn't about specifically not doing this for embedded content.  It was a compromise to keep code complexity down.
In order to tag every request from IE while still supporting the feature to not tag at all when the BHO is disabled, we have to have hooks in place at many more places (not to mention supporting the different things IE6, 7 and 8 do).  So, as a compromise we decided to keep it down to only the single hook that allows us to tag top level requests.

However, I think we should be able to support what you ask.  Since CF controls requests for embedded content, we can control the request headers.

Tommi

[Andrea Giammarchi]

Tommi, I've not read full source yet (planning to :D)

But without even imagine the chaos you guys have to deal with I can spot two scenarios:

 1 - BHO disabled
 2 - whatever other case

I agree that BHO disabled should never show chromeframe in the UA, but do you agree that for everything else it should?

Specially for those who would like to serve different/specific content for frame when present, it does not matter if it is top level or not, something strictly related to the client and the DOM hierarchy, it matters if the top level supports Chrome Frame and everything else could be easily driven in both client and server side.

If there is a server side check for whatever reason about chromeframe possbility, leave it there, otherwise if BHO has been disabled, don't show anything.

Being BHO disabled in my opinion a rare/nonsense case (if there is the possibility why disable it rather than uninstall ...) I would always send chromeframe in the UA removing it as last process ever for each call before UA is sent.

If you need to anticipate the UA basing the change via registry ... well, I kinda agree things are not that simple here since I don't really know when IE network layer reads the registry the instant before the UA is sent so, in few words, I hope you'll solve soon this UA ambiguity (disabled or not? ... this is the only thing that matter, just my opinion)

Thanks for the reply and best regards.

[Alex Russell]

On Thu, Oct 29, 2009 at 3:15 PM, Andrea Giammarchi
<andrea.g...@gmail.com> wrote:
> Tommi, I've not read full source yet (planning to :D)
>
> But without even imagine the chaos you guys have to deal with I can spot two
> scenarios:
>
>  1 - BHO disabled
>  2 - whatever other case
>
> I agree that BHO disabled should never show chromeframe in the UA, but do
> you agree that for everything else it should?

It'd be nice, but I'm not entirely sure it's practical given what
Tommi has told me about how the new UA augmentation is being done. It
seems reasonable to me to:

* having the UA augmented for all top-level page requests
* all resources loaded from within a GCF-hosted page

Does that fit your definition of "sane"?

[Andrea Giammarchi]

On Thu, Oct 29, 2009 at 10:58 PM, Alex Russell <sligh...@google.com> wrote:

It'd be nice, but I'm not entirely sure it's practical given what
Tommi has told me about how the new UA augmentation is being done. It
seems reasonable to me to:

  * having the UA augmented for all top-level page requests
  * all resources loaded from within a GCF-hosted page

Does that fit your definition of "sane"?

if this means than as soon as the top level page/tab activates GCF everything else will have chromeframe in the UA this is basically what I was wondering/asking at the beginning so definitively yes, that would fit my definition of sane and all cases I wrote will properly deal with it, thanks.

Regards

[Andrea Giammarchi]

P.S. my problem now is that my IE8 does not expose the UA as it suppose to do ... I have no version after chromeframe keyword, but I could have messed up manually my registry so no worries :D