We are experiencing a problem widely discussed on the internet, where as if Google Chrome Frame plug-in is installed for Internet Explorer, MapQuest does not work as expected. Here is the error we are experiencing:
Line: 983
Char: 9
Error: 'm3.dotcom.controller.MCP' is a null or not an object
In the Google Group post, it looks like you folks contacted MapQuest and they simply told you to uninstall. That is the same solution posted elsewhere, having to uninstall the plug-in to get the functionality back. Most notably in this:
"Thanks for reporting this. I've just debugged into MapQuest's client-side UserAgent parser, and see that it gets confused by the presence of "chromeframe/w.x.y.z". I'll try to get in touch with someone there so they can fix their scripts.
Cheers,
Greg "
Further in that thread, discussions are to switch to Google Maps.
Just wanted to check if the only existing viable solutions are:
On Fri, Apr 13, 2012 at 11:02 AM, Rose, Derek <DR...@iso-ne.com> wrote: > We are experiencing a problem widely discussed on the internet, where as > if Google Chrome Frame plug-in is installed for Internet Explorer, MapQuest > does not work as expected. Here is the error we are experiencing:
> Line: 983
> Char: 9
> Error: ‘m3.dotcom.controller.MCP’ is a null or not an object
> In the Google Group post, it looks like you folks contacted MapQuest and > they simply told you to uninstall. That is the same solution posted > elsewhere, having to uninstall the plug-in to get the functionality back. > Most notably in this:
> *“**Thanks for reporting this. I've just debugged into MapQuest's > client-side > UserAgent parser, and see that it gets confused by the presence of > "chromeframe/w.x.y.z". I'll try to get in touch with someone there so > they > can fix their scripts. *
> *Cheers, *
> *Greg “*
> Further in that thread, discussions are to switch to Google Maps.
> Just wanted to check if the only existing viable solutions are:
> **1. **Uninstall Google Chrome Frame
> **2. **Switch to Google Maps
Those two work, and a third option is working its way through the release process:
Then, you can create wildstar patterns that will prevent the CF User Agent from being sent to specific sites, so e.g. to make MapQuest work you could add a REG_SZ value named:
*mapquest.com* to the above key and CF will send a user-agent string to MapQuest that stops it from breaking.
> Any assistance anyone can provide is appreciated.
> Derek
> -- > You received this message because you are subscribed to the Google Groups > "Google-chrome-frame" group. > To post to this group, send email to google-chrome-frame@googlegroups.com. > To unsubscribe from this group, send email to > google-chrome-frame+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/google-chrome-frame?hl=en.
On Friday, April 13, 2012 11:02:16 AM UTC-4, Rose, Derek wrote:
> We are experiencing a problem widely discussed on the internet, where as > if Google Chrome Frame plug-in is installed for Internet Explorer, MapQuest > does not work as expected. Here is the error we are experiencing:
> Line: 983
> Char: 9
> Error: ‘m3.dotcom.controller.MCP’ is a null or not an object
> In the Google Group post, it looks like you folks contacted MapQuest and > they simply told you to uninstall. That is the same solution posted > elsewhere, having to uninstall the plug-in to get the functionality back.
> Most notably in this:
> *“**Thanks for reporting this. I've just debugged into MapQuest's > client-side > UserAgent parser, and see that it gets confused by the presence of > "chromeframe/w.x.y.z". I'll try to get in touch with someone there so > they > can fix their scripts. *
> *Cheers, *
> *Greg “*
> Further in that thread, discussions are to switch to Google Maps.
> Just wanted to check if the only existing viable solutions are:
> 1. Uninstall Google Chrome Frame
> 2. Switch to Google Maps
> Any assistance anyone can provide is appreciated.
I downloaded the Dev version of Chrome Frame, and it's version 20.0.1096.1
I went to create the registry key, and had to create the KEY for Chrome Frame and then ExcludeUAFromDomain as these did not exist. I then created the REG_SZ with a value of *mapquest.com*, rebooted the machine and did not get the desired result. I know you didn't specify, but I tried this both in the HKCU and HKLM hives. I've attached a screenshot of my registry, please let me know if I'm doing something incorrectly or if there are other files I can provide for analysis. This is a very important feature for us.
Thanks,
Derek
From: google-chrome-frame@googlegroups.com [mailto:google-chrome-frame@googlegroups.com] On Behalf Of Robert Shield Sent: Saturday, April 14, 2012 12:42 AM To: google-chrome-frame@googlegroups.com Subject: Re: [google-chrome-frame:2932] Problem with GCF/IE and MapQuest
On Fri, Apr 13, 2012 at 11:02 AM, Rose, Derek <DR...@iso-ne.com> wrote:
We are experiencing a problem widely discussed on the internet, where as if Google Chrome Frame plug-in is installed for Internet Explorer, MapQuest does not work as expected. Here is the error we are experiencing:
Line: 983
Char: 9
Error: 'm3.dotcom.controller.MCP' is a null or not an object
In the Google Group post, it looks like you folks contacted MapQuest and they simply told you to uninstall. That is the same solution posted elsewhere, having to uninstall the plug-in to get the functionality back. Most notably in this:
"Thanks for reporting this. I've just debugged into MapQuest's client-side UserAgent parser, and see that it gets confused by the presence of "chromeframe/w.x.y.z". I'll try to get in touch with someone there so they can fix their scripts.
Cheers,
Greg "
Further in that thread, discussions are to switch to Google Maps.
Just wanted to check if the only existing viable solutions are:
1. Uninstall Google Chrome Frame
2. Switch to Google Maps
Those two work, and a third option is working its way through the release process:
Then, you can create wildstar patterns that will prevent the CF User Agent from being sent to specific sites, so e.g. to make MapQuest work you could add a REG_SZ value named:
*mapquest.com* to the above key and CF will send a user-agent string to MapQuest that stops it from breaking.
Any assistance anyone can provide is appreciated.
Derek
-- You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group. To post to this group, send email to google-chrome-frame@googlegroups.com. To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com <mailto:google-chrome-frame%2Bunsubscribe@googlegroups.com> . For more options, visit this group at http://groups.google.com/group/google-chrome-frame?hl=en.
-- You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group. To post to this group, send email to google-chrome-frame@googlegroups.com. To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-chrome-frame?hl=en.
Sounds promising, I'll check it out. On a somewhat related note, how would we pass a resource within our Local Intranet zone to this? In the future, it will have a domain name, but right now I'm working with something else that is simply being accessed from a fileserver and having similar issues caused by the CF plug-in. So, I'd need to exempt something like...
\\fileserver\share\share\share\file.htm <file:///\\fileserver\share\share\share\file.htm> for example
From: google-chrome-frame@googlegroups.com [mailto:google-chrome-frame@googlegroups.com] On Behalf Of Robert Shield Sent: Saturday, April 14, 2012 12:42 AM To: google-chrome-frame@googlegroups.com Subject: Re: [google-chrome-frame:2932] Problem with GCF/IE and MapQuest
On Fri, Apr 13, 2012 at 11:02 AM, Rose, Derek <DR...@iso-ne.com> wrote:
We are experiencing a problem widely discussed on the internet, where as if Google Chrome Frame plug-in is installed for Internet Explorer, MapQuest does not work as expected. Here is the error we are experiencing:
Line: 983
Char: 9
Error: 'm3.dotcom.controller.MCP' is a null or not an object
In the Google Group post, it looks like you folks contacted MapQuest and they simply told you to uninstall. That is the same solution posted elsewhere, having to uninstall the plug-in to get the functionality back. Most notably in this:
"Thanks for reporting this. I've just debugged into MapQuest's client-side UserAgent parser, and see that it gets confused by the presence of "chromeframe/w.x.y.z". I'll try to get in touch with someone there so they can fix their scripts.
Cheers,
Greg "
Further in that thread, discussions are to switch to Google Maps.
Just wanted to check if the only existing viable solutions are:
1. Uninstall Google Chrome Frame
2. Switch to Google Maps
Those two work, and a third option is working its way through the release process:
Then, you can create wildstar patterns that will prevent the CF User Agent from being sent to specific sites, so e.g. to make MapQuest work you could add a REG_SZ value named:
*mapquest.com* to the above key and CF will send a user-agent string to MapQuest that stops it from breaking.
Any assistance anyone can provide is appreciated.
Derek
-- You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group. To post to this group, send email to google-chrome-frame@googlegroups.com. To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com <mailto:google-chrome-frame%2Bunsubscribe@googlegroups.com> . For more options, visit this group at http://groups.google.com/group/google-chrome-frame?hl=en.
-- You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group. To post to this group, send email to google-chrome-frame@googlegroups.com. To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/google-chrome-frame?hl=en.
> Then, you can create wildstar patterns that will prevent the CF User Agent
> from being sent to specific sites, so e.g. to make MapQuest work you could
> add a REG_SZ value named:
> *mapquest.com* to the above key and CF will send a user-agent string to
> MapQuest that stops it from breaking.
>> Then, you can create wildstar patterns that will prevent the CF User Agent
>> from being sent to specific sites, so e.g. to make MapQuest work you could
>> add a REG_SZ value named:
>> *mapquest.com* to the above key and CF will send a user-agent string to
>> MapQuest that stops it from breaking.
> --
> You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group.
> To post to this group, send email to google-chrome-frame@googlegroups.com.
> To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/google-chrome-frame?hl=en.
I realize that this is a tiny problem, but it has caused my
organization to yank Chrome Frame from all PCs that we rolled it out
to (10,000+). The problem was that was got a mass influx of tickets
regarding mapquest.com issues came rolling in because our corporate
travel dept uses that to double check people's mileage before
reimbursement. Everyone panicked and instead of researching the issue
it was pulled off the machines. Obviously, because of this forum we
have identified the actual issue at hand and could easily push it back
out, but now upper management is balking at the idea because if
mapquest.com was broken what else on the internet is broken. Any site
that parses the word chrome from the UA string is likely going to have
a problem and mapquest is probably not the only one.
I guess I really don't understand why Chrome Frame is changing the UA
string period. If the meta tag calls for Chrome Frame, can the plugin
not tell without the UA string saying "chromeframe/20.0.1130.1;"? If
the UA string was unchanged then mapquest wouldn't have problems
except for lazy developers string parsing the UA string for "*chrome*"
<SIGH>
On Apr 27, 4:56 am, Alex Russell <slightly...@google.com> wrote:
> >> Then, you can create wildstar patterns that will prevent the CF User Agent
> >> from being sent to specific sites, so e.g. to make MapQuest work you could
> >> add a REG_SZ value named:
> >> *mapquest.com* to the above key and CF will send a user-agent string to
> >> MapQuest that stops it from breaking.
> > --
> > You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group.
> > To post to this group, send email to google-chrome-frame@googlegroups.com.
> > To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/google-chrome-frame?hl=en.
I don't necessarily agree it can be "easily pushed back out", as at least I have not been able to implement the suggestions and produce the desired results. It's possible I didn't do the keys correctly or have the correct version, but I submitted the info I had and have not heard anything back. Are you making an assumption, or were you able to configure something in a way to disable the GCF for a domain?
Your point is valid though - because even if this is implemented correctly, you are at the mercy of having your users discover websites that don't work. This would undoubtedly be unpopular with management.
-----Original Message-----
From: google-chrome-frame@googlegroups.com [mailto:google-chrome-frame@googlegroups.com] On Behalf Of pattont
Sent: Thursday, May 10, 2012 2:24 PM
To: Google-chrome-frame
Subject: [google-chrome-frame:3005] Re: Problem with GCF/IE and MapQuest
I realize that this is a tiny problem, but it has caused my organization to yank Chrome Frame from all PCs that we rolled it out to (10,000+). The problem was that was got a mass influx of tickets regarding mapquest.com issues came rolling in because our corporate travel dept uses that to double check people's mileage before reimbursement. Everyone panicked and instead of researching the issue it was pulled off the machines. Obviously, because of this forum we have identified the actual issue at hand and could easily push it back out, but now upper management is balking at the idea because if mapquest.com was broken what else on the internet is broken. Any site that parses the word chrome from the UA string is likely going to have a problem and mapquest is probably not the only one.
I guess I really don't understand why Chrome Frame is changing the UA string period. If the meta tag calls for Chrome Frame, can the plugin not tell without the UA string saying "chromeframe/20.0.1130.1;"? If the UA string was unchanged then mapquest wouldn't have problems except for lazy developers string parsing the UA string for "*chrome*"
<SIGH>
On Apr 27, 4:56 am, Alex Russell <slightly...@google.com> wrote:
> +robert
> On Fri, Apr 20, 2012 at 3:50 PM, Vallu <vkoivu...@gmail.com> wrote:
> > Hello Robert,
> >> Then, you can create wildstar patterns that will prevent the CF > >> User Agent from being sent to specific sites, so e.g. to make > >> MapQuest work you could add a REG_SZ value named:
> >> *mapquest.com* to the above key and CF will send a user-agent > >> string to MapQuest that stops it from breaking.
> > --
> > You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group.
> > To post to this group, send email to google-chrome-frame@googlegroups.com.
> > To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com.
> > For more options, visit this group athttp://groups.google.com/group/google-chrome-frame?hl=en.
--
You received this message because you are subscribed to the Google Groups "Google-chrome-frame" group.
To post to this group, send email to google-chrome-frame@googlegroups.com.
To unsubscribe from this group, send email to google-chrome-frame+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-chrome-frame?hl=en.
On Wed, May 16, 2012 at 1:04 PM, Rose, Derek <DR...@iso-ne.com> wrote:
> I don't necessarily agree it can be "easily pushed back out", as at least
> I have not been able to implement the suggestions and produce the desired
> results. It's possible I didn't do the keys correctly or have the correct
> version, but I submitted the info I had and have not heard anything back.
> Are you making an assumption, or were you able to configure something in a
> way to disable the GCF for a domain?
> Your point is valid though - because even if this is implemented
> correctly, you are at the mercy of having your users discover websites that
> don't work. This would undoubtedly be unpopular with management.
We've heard of very few sites which break due to such poor UA-sniffing.
That said, we're looking into a compatibility-list approach based on recent
work cited earlier in the thread. You shouldn't need to be maintaining such
a list by yourself.
> -----Original Message-----
> From: google-chrome-frame@googlegroups.com [mailto:
> google-chrome-frame@googlegroups.com] On Behalf Of pattont
> Sent: Thursday, May 10, 2012 2:24 PM
> To: Google-chrome-frame
> Subject: [google-chrome-frame:3005] Re: Problem with GCF/IE and MapQuest
> I realize that this is a tiny problem, but it has caused my organization
> to yank Chrome Frame from all PCs that we rolled it out to (10,000+). The
> problem was that was got a mass influx of tickets regarding mapquest.comissues came rolling in because our corporate travel dept uses that to
> double check people's mileage before reimbursement. Everyone panicked and
> instead of researching the issue it was pulled off the machines. Obviously,
> because of this forum we have identified the actual issue at hand and could
> easily push it back out, but now upper management is balking at the idea
> because if mapquest.com was broken what else on the internet is broken.
> Any site that parses the word chrome from the UA string is likely going to
> have a problem and mapquest is probably not the only one.
> I guess I really don't understand why Chrome Frame is changing the UA
> string period. If the meta tag calls for Chrome Frame, can the plugin not
> tell without the UA string saying "chromeframe/20.0.1130.1;"? If the UA
> string was unchanged then mapquest wouldn't have problems except for lazy
> developers string parsing the UA string for "*chrome*"
> <SIGH>
> On Apr 27, 4:56 am, Alex Russell <slightly...@google.com> wrote:
> > +robert
> > On Fri, Apr 20, 2012 at 3:50 PM, Vallu <vkoivu...@gmail.com> wrote:
> > > Hello Robert,
> > > thanks again for implementing the change in GCF UA behaviour. In a
> > >Windows XP+IE8 virtual test machine, I installed GCF dev version
> > > 20.0.1105.2 (Official Build 132863) dev-m from here:
> > >http://www.google.com/chromeframe/eula.html?extra=devchannel&quickena..
> ..
> > > Then I made the following changes in the Windows registry, i.e. a
> > > new REG_SZ key.
> > >> Then, you can create wildstar patterns that will prevent the CF
> > >> User Agent from being sent to specific sites, so e.g. to make
> > >> MapQuest work you could add a REG_SZ value named:
> > >> *mapquest.com* to the above key and CF will send a user-agent
> > >> string to MapQuest that stops it from breaking.
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "Google-chrome-frame" group.
> > > To post to this group, send email to
> google-chrome-frame@googlegroups.com.
> > > To unsubscribe from this group, send email to
> google-chrome-frame+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://
> groups.google.com/group/google-chrome-frame?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "Google-chrome-frame" group.
> To post to this group, send email to google-chrome-frame@googlegroups.com.
> To unsubscribe from this group, send email to
> google-chrome-frame+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-chrome-frame?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "Google-chrome-frame" group.
> To post to this group, send email to google-chrome-frame@googlegroups.com.
> To unsubscribe from this group, send email to
> google-chrome-frame+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-chrome-frame?hl=en.
On Thu, May 10, 2012 at 7:24 PM, pattont <patt...@gmail.com> wrote:
> I realize that this is a tiny problem, but it has caused my
> organization to yank Chrome Frame from all PCs that we rolled it out
> to (10,000+). The problem was that was got a mass influx of tickets
> regarding mapquest.com issues came rolling in because our corporate
> travel dept uses that to double check people's mileage before
> reimbursement. Everyone panicked and instead of researching the issue
> it was pulled off the machines. Obviously, because of this forum we
> have identified the actual issue at hand and could easily push it back
> out, but now upper management is balking at the idea because if
> mapquest.com was broken what else on the internet is broken. Any site
> that parses the word chrome from the UA string is likely going to have
> a problem and mapquest is probably not the only one.
> I guess I really don't understand why Chrome Frame is changing the UA
> string period.
Many sites -- including many of the largest websites -- serve different
content based on UA. Adding "chromeframe" allows them to know (on the
server side) that they can treat the browser as Chrome if they include the
meta/header. We toyed with sending a separate header, but proxies tend to
strip headers, leading to hard-to-diagnose bugs.
That said, we don't know of many sites that are as busted as MapQuest.
We've had very few reports of similar issues and MapQuest stands alone in
both doing the wrong thing and refusing to fix it.
> If the meta tag calls for Chrome Frame, can the plugin
> not tell without the UA string saying "chromeframe/20.0.1130.1;"? If
> the UA string was unchanged then mapquest wouldn't have problems
> except for lazy developers string parsing the UA string for "*chrome*"
> <SIGH>
> On Apr 27, 4:56 am, Alex Russell <slightly...@google.com> wrote:
> > +robert
> > On Fri, Apr 20, 2012 at 3:50 PM, Vallu <vkoivu...@gmail.com> wrote:
> > > Hello Robert,
> > > thanks again for implementing the change in GCF UA behaviour. In a
> > > Windows XP+IE8 virtual test machine, I installed GCF dev version
> > > 20.0.1105.2 (Official Build 132863) dev-m from here:
> > >http://www.google.com/chromeframe/eula.html?extra=devchannel&quickena..
> ..
> > > Then I made the following changes in the Windows registry, i.e. a new
> > > REG_SZ key.
> > >> Then, you can create wildstar patterns that will prevent the CF User
> Agent
> > >> from being sent to specific sites, so e.g. to make MapQuest work you
> could
> > >> add a REG_SZ value named:
> > >> *mapquest.com* to the above key and CF will send a user-agent string
> to
> > >> MapQuest that stops it from breaking.
> > > --
> > > You received this message because you are subscribed to the Google
> Groups "Google-chrome-frame" group.
> > > To post to this group, send email to
> google-chrome-frame@googlegroups.com.
> > > To unsubscribe from this group, send email to
> google-chrome-frame+unsubscribe@googlegroups.com.
> > > For more options, visit this group athttp://
> groups.google.com/group/google-chrome-frame?hl=en.
> --
> You received this message because you are subscribed to the Google Groups
> "Google-chrome-frame" group.
> To post to this group, send email to google-chrome-frame@googlegroups.com.
> To unsubscribe from this group, send email to
> google-chrome-frame+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-chrome-frame?hl=en.
On Friday, April 20, 2012 9:50:58 AM UTC-4, Vallu wrote:
> Hello Robert,
> thanks again for implementing the change in GCF UA behaviour. In a > Windows XP+IE8 virtual test machine, I installed GCF dev version > 20.0.1105.2 (Official Build 132863) dev-m from here:
> > Then, you can create wildstar patterns that will prevent the CF User > Agent > > from being sent to specific sites, so e.g. to make MapQuest work you > could > > add a REG_SZ value named:
> > *mapquest.com* to the above key and CF will send a user-agent string to > > MapQuest that stops it from breaking.
