summaryrefslogtreecommitdiffstats
path: root/chrome_frame/utils.cc
Commit message (Collapse)AuthorAgeFilesLines
* Only switch to cf for text/html. With opt-in URLs we could mark a URL to be ↵tommi@chromium.org2010-04-211-2/+14
| | | | | | | | | | | loaded in CF regardless of the target mime type. If CF turns around and wants to download the target, we would hit an infinite loop. TEST=Verify that issue 40046 is resolved. OptIn urls should work with the moniker patch and downloads should not cause an infinite loop. BUG=40046 Review URL: http://codereview.chromium.org/1715004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45226 0039d316-1c4b-4281-b951-d872f2087c98
* In ChromeFrame with the moniker patch enabled we should not process optin ↵ananta@chromium.org2010-04-201-0/+14
| | | | | | | | | | | | urls in the BHO. Fixes bug http://code.google.com/p/chromium/issues/detail?id=42155 Bug=42155 Review URL: http://codereview.chromium.org/1706003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@45117 0039d316-1c4b-4281-b951-d872f2087c98
* With the ChromeFrame IMoniker patch in the referrer would not propagate ↵ananta@chromium.org2010-04-161-0/+65
| | | | | | | | | | | | | | | | | | | | correctly to Chrome when we switch from IE to CF. In ChromeFrame the referrer is set in the navigation manager which receives this in the IHttpNegotiate::BeginningTransaction patch. When we switch from IE to cF via the moniker patch we receive two calls to BeginningTransaction, the first one with the referrer and the other one without the referrer for the same URL causing the referrer to be overwritten. Fix is to handle this case. The referrer is cleared in our BeforeNavigate notification. I also moved some functions to chrome frame utils as part of this CL. Fixes bug http://code.google.com/p/chromium/issues/detail?id=41680 Bug=41680 Review URL: http://codereview.chromium.org/1653006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44733 0039d316-1c4b-4281-b951-d872f2087c98
* IE would not switch into ChromeFrame if the url being navigated to had an ↵ananta@chromium.org2010-04-131-0/+19
| | | | | | | | | | | | | | | | | | | | anchor. The IsTopLevelUrl function exposed by the navigation manager would compare the URL received in the BHO which has the anchor and the URL received from the anchor which does not have the anchor. As a result we would not wrap the bind status callback which caused this issue. The IsTopLevelUrl function now compares the URLs after stripping the anchor portion in the URL. Should fix bug http://code.google.com/p/chromium/issues/detail?id=38265. This only works if the moniker patch is enabled. Bug=38265 Test=Covered by unit test. Review URL: http://codereview.chromium.org/1559027 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@44309 0039d316-1c4b-4281-b951-d872f2087c98
* In the GetIETemporaryFilesFolder helper function in ChromeFrame we should ↵ananta@chromium.org2010-04-061-2/+0
| | | | | | | | | | | | not be freeing the relative pidl. It is a pointer into the absolute pidl. Thanks to Tommi for pointing this out. Bug=none Review URL: http://codereview.chromium.org/1568017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43734 0039d316-1c4b-4281-b951-d872f2087c98
* Fix a ChromeFrame crash which was reported in the crash server in the helper ↵ananta@chromium.org2010-04-051-22/+39
| | | | | | | | | | | | | | | | | function to return the path to the IE temporary internet files folder. The crash occurs because of dereferencing a NULL parent IShellFolder interface. Fix is to bail out and use the SHGetFolderPath function if the SHGetFolderLocation and the SHBindToParent APIs fail for some reason. The SHGetFolderPath function has a limit of MAX_PATH characters. Added a unit test for the GetIETemporaryFilesFolder helper function. Fixes bug http://code.google.com/p/chromium/issues/detail?id=40266 Bug=40266 Review URL: http://codereview.chromium.org/1523010 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43639 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes GCF perf tests in prep for re-enabling them on the bots.slightlyoff@chromium.org2010-03-261-0/+9
| | | | | | | | | BUG=36734 TEST=build/run chrome_frame_perftests.exe, note that they all run now Review URL: http://codereview.chromium.org/1433002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42870 0039d316-1c4b-4281-b951-d872f2087c98
* 3rd try. *sigh*slightlyoff@chromium.org2010-03-261-0/+29
| | | | | | | | | | | | | See: http://codereview.chromium.org/858003 TBR=tommi BUG=22846 TEST=On IE 8, clear the cache entirely, watch GCF launch (via task manager) Review URL: http://codereview.chromium.org/1343004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42732 0039d316-1c4b-4281-b951-d872f2087c98
* Reverting this CL to see if this fixes chrome frame unit test failures.ananta@chromium.org2010-03-251-29/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert 42684 - Implements IDeleteBrowsing history and moves the GCF profile into the IE TIF directory for nonpriv mode users on IE < 8. Implementation notes: Earlier work enabled InPrivate browsing detection and mapped it to creation of an incognito profile instance.Privacy features and how they operate with this change: "Delete Browsing History": IE 6 & 7: all history (including databases) is deleted if cache is cleared *WITHOUT* an active Chrome process holding references to the profile resources. If GCF is rendering a page when the cache is cleared, history *WILL NOT* be deleted on the GCF side, however GCF will continue to operate and IE will remove all other history artifacts as usual. IE 8: GCF cache is cleared in alignment with the options specified by the user. Clearing Temporary Internet Files may destroy the profile entirely, and so we need to consider not moving the GCF profile on IE 8. "InPrivate Filtering": IE 8 (only): more testing required. "InPrivate Browsing": IE 8 (only): pages rendered in GCF *after* entering InPrivate mode are not persisted to disk (use an incognito wrapper on the specified profile). Currently displayed pages are not effected by the switch, although refreshing them will invoke the new behavior. Generally speaking, BHO's are disabled by IE 8 while in InPrivate mode, so entering this state is wonky to begin with but we handle it as well as can be expected. BUG=22846 TEST=On IE 8, clear the cache entirely, note GCF entries in DbgView (better tests coming) Review URL: http://codereview.chromium.org/858003 TBR=slightlyoff@chromium.org Review URL: http://codereview.chromium.org/1353002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42691 0039d316-1c4b-4281-b951-d872f2087c98
* Implements IDeleteBrowsing history and moves the GCF profile into the IE TIF ↵slightlyoff@chromium.org2010-03-251-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | directory for non-priv mode users on IE < 8. Implementation notes: Earlier work enabled InPrivate browsing detection and mapped it to creation of an incognito profile instance.Privacy features and how they operate with this change: "Delete Browsing History": IE 6 & 7: all history (including databases) is deleted if cache is cleared *WITHOUT* an active Chrome process holding references to the profile resources. If GCF is rendering a page when the cache is cleared, history *WILL NOT* be deleted on the GCF side, however GCF will continue to operate and IE will remove all other history artifacts as usual. IE 8: GCF cache is cleared in alignment with the options specified by the user. Clearing Temporary Internet Files may destroy the profile entirely, and so we need to consider not moving the GCF profile on IE 8. "InPrivate Filtering": IE 8 (only): more testing required. "InPrivate Browsing": IE 8 (only): pages rendered in GCF *after* entering InPrivate mode are not persisted to disk (use an incognito wrapper on the specified profile). Currently displayed pages are not effected by the switch, although refreshing them will invoke the new behavior. Generally speaking, BHO's are disabled by IE 8 while in InPrivate mode, so entering this state is wonky to begin with but we handle it as well as can be expected. BUG=22846 TEST=On IE 8, clear the cache entirely, note GCF entries in DbgView (better tests coming) Review URL: http://codereview.chromium.org/858003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42684 0039d316-1c4b-4281-b951-d872f2087c98
* Add a simple resource loader to Chrome Frame that is capable of finding, ↵robertshield@chromium.org2010-03-241-18/+9
| | | | | | | | | | | | | | | loading and extracting resources from the Chrome locale DLLs. Add the Chrome Frame resource strings to the Chrome .grds so they get built directly into the Chrome locale dlls. There is one remaining todo here, which is to load the dialog template into a grd + rc somewhere (probably in generated_resources.grd) and then get CF to load dialog templates from a different module. Will do that in another patch. BUG=24305 TEST=Chrome Frame when loaded on machines whose locales are not US English will display strings appropriate to those locales. Review URL: http://codereview.chromium.org/1240001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42423 0039d316-1c4b-4281-b951-d872f2087c98
* Initial support for IE View->Privacy. To support this menu option the active ↵ananta@chromium.org2010-03-191-0/+27
| | | | | | | | | | | | | | | | | | | | | | | document now implements the Exec command for the CGID_ShellDocView group and command id 75. We invoke the DoPrivacyDlg function exported by shdocvw and pass in our implementation of the IEnumPrivacyServices interface. The actual privacy data is gathered and maintained by the UrlmonUrlRequestManager. If we detect a privacy violation we notify the shell browser via the ITridentService2::FirePrivacyImpactedStateChange function which ensures that IE displays the privacy icon. Thanks to stoyan for his help in getting this done. I will add tests in a followup CL. Fixes bug http://code.google.com/p/chromium/issues/detail?id=25479 Bug=25479 Review URL: http://codereview.chromium.org/1127003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@42113 0039d316-1c4b-4281-b951-d872f2087c98
* IE6 would not switch to ChromeFrame if the url being navigated to contained ↵ananta@chromium.org2010-03-161-1/+17
| | | | | | | | | | | | | | | | | | | | | an anchor. This is presumably because from IE6's perspecive nothing changed. To workaround this issue, we stash the complete url away in the navigation manager and remove it from the URL being navigated to. When the Chrome active document loads we read the actual url from the navigation manager and initiate a navigation to this URL. There is one issue with this approach though. The actual URL in the address bar in IE6 does not contain the anchor tag. Will address that in a follow up CL. This fixes bug http://code.google.com/p/chromium/issues/detail?id=38265 Bug=38265 Test=Covered by existing ChromeFrame anchor URL navigation tests. Review URL: http://codereview.chromium.org/1022003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41776 0039d316-1c4b-4281-b951-d872f2087c98
* Fix #1 for multiple request issue (both POST and GET) after activating the ↵tommi@chromium.org2010-03-121-0/+13
| | | | | | | | | | | | | | | | | | | | | onhttpequiv approach. There's a ton going on here. Brief summary: I'm introducing a caching layer for top level page requests that we then use again when switching the document from mshtml to cf. Also in this change list: * Removing the previous way of shifting the document moniker over to the worker thread when a new chrome document is created. Instead we use a request cache object. * Refactoring the part of the Bho class that offered access to it via TLS. This was needed for better testability but also makes (imho) the separation clearer and will possibly help in the future if we don't have a Bho object. * Added a bit of logging that I'd prefer to keep in there until we're confident enough with onhttpequiv. * Enabling two previously disabled tests (the ones I added for multiple requests) * Adding several more unit tests for the new code. Review URL: http://codereview.chromium.org/668187 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41495 0039d316-1c4b-4281-b951-d872f2087c98
* win: string_util.h -> utf_string_conversions.h fix.jhawkins@google.com2010-03-111-0/+1
| | | | | | | | | BUG=none TEST=none Review URL: http://codereview.chromium.org/830002 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@41292 0039d316-1c4b-4281-b951-d872f2087c98
* Adding a little utility function to make logging guids easiertommi@chromium.org2010-03-011-0/+6
| | | | | | | | | | | and a dlog to see when we decide that a request is a subframe request. TEST=Unit test is provided. BUG=none Review URL: http://codereview.chromium.org/660289 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@40288 0039d316-1c4b-4281-b951-d872f2087c98
* First batch of context menu testsamit@chromium.org2010-02-121-0/+9
| | | | | | | | | | | | | | | | Refactored various methods to send keyboard and mouse input. Fixed the context menu focus issue on IE7. Improved existing tests to make them less flaky and added 3 new tests for context menu items. BUG=34673 TEST=new tests added Review URL: http://codereview.chromium.org/604014 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38905 0039d316-1c4b-4281-b951-d872f2087c98
* Fix Navigation failed testamit@chromium.org2010-02-041-2/+2
| | | | | | | | | | | | Also fix a bug in SetConfigInt to create the 'ChromeFrame' config key if it does not exist. BUG=24104 TEST=CFACWithChrome.NavigateFailed Review URL: http://codereview.chromium.org/560041 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@38103 0039d316-1c4b-4281-b951-d872f2087c98
* Remove cf: protocolamit@chromium.org2010-02-031-1/+2
| | | | | | | | | | | | | | | | | | | | Well, almost. cf: is now changed to gcf: protocol. gcf: protocol now is supported only for the following cases: 1. gcf:attach_external_tabXXX urls. These are URLs used internally by Chrome Frame to implement window.open 2. gcf:about:xxx 3. gcf:view-source:xxx 4 For any other URLs ONLY if it is enabled by setting a registry value 'EnableGCFProtocol' to 1 in HKCU\Software\Google\ChromeFrame BUG=22721,23006,23175,29350 TEST=changed existing cf: tests to new gcf: tests, added a new test for cf:view-source Review URL: http://codereview.chromium.org/562008 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37981 0039d316-1c4b-4281-b951-d872f2087c98
* Disabling onhttpequiv again due to page reload issues.tommi@chromium.org2010-01-301-0/+5
| | | | | | | | | TEST=Make sure unit tests still pass. BUG=33332 Review URL: http://codereview.chromium.org/555178 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@37584 0039d316-1c4b-4281-b951-d872f2087c98
* Implement OptInUrls using the same mechanism we use in the onhttpequiv ↵tommi@chromium.org2010-01-221-1/+2
| | | | | | | | | | | | | notification. A noteworthy change here is that OptInUrls doesn't rely on cf: anymore. TEST=The OptInUrls registry key should start working properly again. BUG=32660 Review URL: http://codereview.chromium.org/549129 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36874 0039d316-1c4b-4281-b951-d872f2087c98
* If we navigate to a URL which has an anchor in IE, which eventually ends up ↵ananta@chromium.org2010-01-221-3/+23
| | | | | | | | | | | | | | | | | | | | | in ChromeFrame, the actual URL queried from the moniker passed in to our implementation of IPersistStream::Load does not have the anchor. It looks like there are some private interfaces exposed by MSHTML and invoked by IEFrame to pass this information over. Our fix is to save away the url received in our Bho BeforeNavigate2 notification and use this URL if available before querying the moniker for the URL. This needs to be done in IPersistStream::Load and in the OnHttpEquiv patch when we initiate a navigation to the actual URL using the moniker. Fixes bug http://code.google.com/p/chromium/issues/detail?id=27270 Bug=27270 Test=Covered by unit test. Review URL: http://codereview.chromium.org/542096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36814 0039d316-1c4b-4281-b951-d872f2087c98
* Updates for onhttpequiv. Preserving the referrer header, zapping the ↵tommi@chromium.org2010-01-161-4/+11
| | | | | | | | | | | | | currently loading document to prevent small documents from executing code. I'm not enabling httpequiv just yet as there are a couple of things I'm working on related to tests that will break once I make the switch. TEST=There should be no change since the code isn't still active but run all tests just to be safe. BUG=none Review URL: http://codereview.chromium.org/545096 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36436 0039d316-1c4b-4281-b951-d872f2087c98
* Querying for one more interface to handle IE8 on XP case. This is what we ↵tommi@chromium.org2010-01-121-12/+27
| | | | | | | | | | | | were hitting on the builder. R=ananta BUG=none TEST=Run all unit tests. This is a second attempt to switch to onhttpequiv. Review URL: http://codereview.chromium.org/543017 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@36009 0039d316-1c4b-4281-b951-d872f2087c98
* Handle right-click->"Save Link As" in the host browser.tommi@chromium.org2009-12-161-0/+19
| | | | | | | | | TEST=Right click on a link in CF and select "save link as". You should immediately get the host browser's download UI. Before there could be a significant wait before this happened. BUG=23561 Review URL: http://codereview.chromium.org/506042 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34783 0039d316-1c4b-4281-b951-d872f2087c98
* Minor change to less confusing variable name in IsSubFrameRequest in ↵robertshield@chromium.org2009-12-161-4/+4
| | | | | | | | | | ChromeFrame utils. TBR=tommi Review URL: http://codereview.chromium.org/474001 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34737 0039d316-1c4b-4281-b951-d872f2087c98
* Use the OnHttpEquiv notification to switch to CF when the http-equiv meta ↵tommi@chromium.org2009-12-111-19/+104
| | | | | | | | | | | | | | | | tag is detected. This implementation is still behind the registry switch (set PatchProtocols to 0 in the registry). I will switch over to it wholesale in a separate patch. We use the same mechanism for re-initiating the navigation we use to transfer downloads over to the host, so I moved the common code to utils.cc and added NavigateBrowserToMoniker. When we see a browser instance attempting to load a CF document, we raise a TLS flag that we catch in HttpNegotiatePatch::ReportProgress when the mime type is being reported. This is the same place where we examine http headers and report the mime type. BUG=n/a TEST=Set PatchProtocols (REG_DWORD) to 0 in the CF HKCU config key and make sure we detect and handle the meta tag as well or better than before. Review URL: http://codereview.chromium.org/489004 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34366 0039d316-1c4b-4281-b951-d872f2087c98
* Allow privileged mode to navigate Chrome Frame to data: URLs. siggi@chromium.org2009-12-101-1/+3
| | | | | | | | | | | For Joi: http://codereview.chromium.org/434121 BUG=none TEST=In privileged mode, set the src attribute to something like "data:text/html,Hello World". Review URL: http://codereview.chromium.org/487009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34252 0039d316-1c4b-4281-b951-d872f2087c98
* Added support for running reliability tests for ChromeFrame on similar lines ↵ananta@chromium.org2009-12-091-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | as Chrome. We only run these tests for IE at this point. The reliability test code for Chrome has been copied and modified accordingly. Other related changes in this CL include the following:- 1. If ChromeFrame is running in headless mode determined by a registry value in HKCU\Software\Google\ChromeFrame we initialize ChromeFrame crash reporting and connect to the Chrome crash server. This would enable us to gather crash dumps from the reliability test runs and report the same. 2. The LowIntegrity fixes for the WebBrowser which Stoyan had done a while back are only needed for IE7 on Vista. For this CL though we just do the requisite hacks if the OS is Vista. For Windows7 the returned IWebBrowser interface pointer works fine. 3. I moved the WebBrowserEventSink to chrome_frame_test_utils as this class is now shared. Fixes portions of http://code.google.com/p/chromium/issues/detail?id=29451 Bug=29451 Review URL: http://codereview.chromium.org/465074 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@34119 0039d316-1c4b-4281-b951-d872f2087c98
* Fix the ChromeFrame build bot redness caused by us incorrectly wrapping ↵ananta@chromium.org2009-12-061-0/+2
| | | | | | | | | | | | protocol sinks which don't have an associated IWebBrowser. TBR=robertshield Review URL: http://codereview.chromium.org/469003 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33942 0039d316-1c4b-4281-b951-d872f2087c98
* Limit the X-UA-Compatible HTTP header-based altering of the mime type ↵robertshield@chromium.org2009-12-041-0/+30
| | | | | | | | | | | performed by Chrome Frame to top-level requests only in IE. BUG=having an iframe that requests a resource that includes the X-UA-Compatible header in the response will trigger CF taking over the page. TEST=BUG doesn't happen anymore. Review URL: http://codereview.chromium.org/465036 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33849 0039d316-1c4b-4281-b951-d872f2087c98
* Fixes to the string MatchPattern functions:tony@chromium.org2009-12-031-1/+1
| | | | | | | | | | | | | | | 1) Make it explicit that it only supports ASCII (since it iterates character by character). 2) Limit the recursion to 16 levels. We could allow more, but in the case of a ?, it has exponential complexity, so I figured 16 was a good stopping point. It seems rare that someone would have more than 16 '?' and '*'s. BUG=28645 Review URL: http://codereview.chromium.org/460047 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33748 0039d316-1c4b-4281-b951-d872f2087c98
* Adding support for Chrome Frame to be loaded via the presence of an ↵robertshield@chromium.org2009-12-031-0/+25
| | | | | | | | | | | | | X-UA-Compatible HTTP header (in addition to the meta tag support). Also pins the CF module into the process such that it won't get unloaded. Doing this to work around how we can get unloaded without unpatching properly. BUG=22802 TEST=Navigate to a web site whose server sends the X-UA-Compatible: chrome=1 HTTP header and ensure that the page is loaded in CF. Review URL: http://codereview.chromium.org/465009 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@33629 0039d316-1c4b-4281-b951-d872f2087c98
* Make UtilChangePersistentNPAPIMarker return true on unregistration ifjoi@chromium.org2009-11-191-1/+5
| | | | | | | | | | | the marker did not previously exist. BUG=none TEST=call the UnregisterNPAPIPlugin entrypoint on npchrome_tab.dll when the NPAPI plug-in is not previously installed with Firefox; it should not return an error. Review URL: http://codereview.chromium.org/402062 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@32480 0039d316-1c4b-4281-b951-d872f2087c98
* Add NPAPI plugin registration persistence code to chrome frame. If the DLL ↵robertshield@chromium.org2009-11-111-0/+47
| | | | | | | | is already registered as an NPAPI plugin, keep that registration information up to date across updates. Review URL: http://codereview.chromium.org/385015 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@31697 0039d316-1c4b-4281-b951-d872f2087c98
* Additional layer of protection to disable funky URLs throughamit@chromium.org2009-10-291-3/+16
| | | | | | | | | | | | view-source in chrome frame BUG=26129 TEST=cf:view-source:javascript:alert('foo') should not work in chrome frame. Review URL: http://codereview.chromium.org/348006 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30417 0039d316-1c4b-4281-b951-d872f2087c98
* Remove the Chrome Frame preprocessor define in chrome_constants.cc and deal ↵robertshield@chromium.org2009-10-281-27/+0
| | | | | | | | | | | | with resulting fallout. Also, remove several instances of Chrome Frame using wstrings instead of FilePaths. The main goal of this patch is to move towards ensuring that Chrome Frame and Google Chrome share binary-identical exes and dlls except for setup.exe and mini_installer.exe. Review URL: http://codereview.chromium.org/338025 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@30290 0039d316-1c4b-4281-b951-d872f2087c98
* Use scoped_array (not scoped_ptr) with new[].kuchhal@chromium.org2009-10-231-1/+1
| | | | | | | | | BUG=24266 TEST=No functional change so make sure nothing changes. Review URL: http://codereview.chromium.org/307045 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29843 0039d316-1c4b-4281-b951-d872f2087c98
* Remove old ap-value munging code in Chrome Frame.robertshield@chromium.org2009-10-211-71/+0
| | | | | | Review URL: http://codereview.chromium.org/303023 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@29696 0039d316-1c4b-4281-b951-d872f2087c98
* Committing patch 256001 for Roger:http://codereview.chromium.org/256001Allow ↵tommi@chromium.org2009-10-011-1/+4
| | | | | | | | Chrome Frame to display chrome-extension URLs when running in privilegedmode.BUG=noneTEST=see unit tests Review URL: http://codereview.chromium.org/246050 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27724 0039d316-1c4b-4281-b951-d872f2087c98
* Initial import of the Chrome Frame codebase. Integration in chrome.gyp ↵slightlyoff@chromium.org2009-09-241-0/+643
coming in a separate CL. BUG=None TEST=None Review URL: http://codereview.chromium.org/218019 git-svn-id: svn://svn.chromium.org/chrome/trunk/src@27042 0039d316-1c4b-4281-b951-d872f2087c98
generated by cgit v1.1 at 2025-02-10 20:23:42 +0000