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:)
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.
On Thu, Oct 29, 2009 at 1:38 AM, Tommi <to...@chromium.org> wrote:
> 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
> On Wed, Oct 28, 2009 at 2:50 PM, Paul Carey <paul.p.ca...@gmail.com>wrote:
>> 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.
> 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.
> 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.
On Thu, Oct 29, 2009 at 3:40 AM, Andrea Giammarchi <
andrea.giammar...@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.
> Anyway, you are right about the top level window and internals so I have
> updated precedent test page with an iframe.
> Regards
> On Thu, Oct 29, 2009 at 1:38 AM, Tommi <to...@chromium.org> wrote:
>> 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
>> On Wed, Oct 28, 2009 at 2:50 PM, Paul Carey <paul.p.ca...@gmail.com>wrote:
>>> 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.
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?
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.
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
On Thu, Oct 29, 2009 at 12:55 PM, 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?
> 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.
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)
On Thu, Oct 29, 2009 at 6:13 PM, Tommi <to...@chromium.org> wrote:
> 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
> On Thu, Oct 29, 2009 at 12:55 PM, Andrea Giammarchi <
> andrea.giammar...@gmail.com> wrote:
>> 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?
>> 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.
On Thu, Oct 29, 2009 at 3:15 PM, Andrea Giammarchi
<andrea.giammar...@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
> 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.
> On Thu, Oct 29, 2009 at 6:13 PM, Tommi <to...@chromium.org> wrote:
>> 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
>> On Thu, Oct 29, 2009 at 12:55 PM, Andrea Giammarchi
>> <andrea.giammar...@gmail.com> wrote:
>>> 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?
>>> 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.
On Thu, Oct 29, 2009 at 10:58 PM, Alex Russell <slightly...@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.
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
On Thu, Oct 29, 2009 at 11:15 PM, Andrea Giammarchi <
> On Thu, Oct 29, 2009 at 10:58 PM, Alex Russell <slightly...@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.
