| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the IE history
while processing a navigation update received for a tab loading state change. This is incorrectly
treated as an internal navigation which messes up the history.
Fix is to not treat the tab loading state change notification as an internal navigation.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=69096
BUG=69096
TEST=None at this point.
Review URL: http://codereview.chromium.org/6284002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@71524 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
TEST=it compiles
BUG=none
Review URL: http://codereview.chromium.org/6028009
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70345 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
Fix up includes, many files including base/win_util don't actually need it.
TEST=it compiles
BUG=none
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70341 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
base namespace. This also fixes references to TLSSlot to
base::ThreadLocalStorage::Slot.
TEST=it compiles
BUG=none
Review URL: http://codereview.chromium.org/5986012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70322 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
needed-use routing IDs to avoid manually unpacking messages-remove data structures from IPC namespace (that should only be used for IPC code, and param traits)Note that I temporarily commented out part of a test in external_tab_test.cc because I couldn't figure out how to get the updated gmock macros to compile.
Review URL: http://codereview.chromium.org/5998006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@70105 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
validation code path
in ChromeFrame now takes in an interface NavigationConstraints which allows the delegateslike
the ActiveX, ActiveDocument and the NPAPI plugins to control the navigation decisions.
We no longer refer to the InternetSecurityManager interface which is IE only for performing
zone decisions in the ChromeFrame NPAPI plugin.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=66118
BUG=66118
TEST=Covered by additional CanNavigate unit tests.
Review URL: http://codereview.chromium.org/5698005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@69101 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POST to a page
in IE should reissue the POST request after bringing up a confirmation dialog.
This CL adds support to ChromeFrame to achieve this. Ideally we would want IE to display
the confirmation dialog for the POST. However the doc object host which is implemented by
IEFrame expects the doc object to implement the IHTMLDocument interface and a bunch of private
interfaces.
To reissue the POST request we save away the POST data and headers in the navigation manager
instance which is per BHO. When we refresh the page in ChromeFrame the active document on
seeing that we have posted data issues a navigation back to the URL with the posted data
and saved headers. All other refreshes continue to work the same way as before, i.e. the
refresh request is sent to Chrome on the automation channel. The confirmation dialog is
put up by the active document with the same text and caption as that in Chrome.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=64901
BUG=64901
TEST=Covered by new ChromeFrame unit test
Review URL: http://codereview.chromium.org/5595002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@68213 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
pages. This CL
fixes that. We need to enable the MSHTML command id IDM_VIEWSOURCE
Fixes bug http://code.google.com/p/chromium/issues/detail?id=64857
BUG=64857
TEST=Launch IE9 and observe that the View->Source menu item is enabled on chrome frame pages.
Review URL: http://codereview.chromium.org/5367011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@67806 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
receive the desired
content are size. To achieve this we first set the desired window styles on the web browser
and then query it for the effective width and height.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=60447
Bug=60447
Test=Covered by existing window open tests.
Review URL: http://codereview.chromium.org/5128002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@66569 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This moves SecurityStyle and PageType into chrome/common/ and removes the
chrome_frame dependency on chrome/browser/tab_contents/. This undoes the
temporary DEPS hack on chrome/common/.
BUG=51409
TEST=compiles
Review URL: http://codereview.chromium.org/4697005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65965 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
behind and would
not render any content until the user clicked on them. This is because in this context
IE8 attempts to inplace activate the object with the active document as the doc host.
We don't support in place activation and return E_NOTIMPL.
However ieframe specifically expects the return value to be OLEOBJ_E_INVALIDVERB and ends
up not sending in the other verbs like OLEIVERB_SHOW, OLEIVERB_UIACTIVATE etc leading to
this problem.
Fixes bug http://b/issue?id=3174688
Bug=3174688
Review URL: http://codereview.chromium.org/4690004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65595 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
The name of this file is a leftover from Windows. Split the command
ids (which are used on all platforms) out, leaving just the
Windows-specific resource IDs in the original file.
TEST=compiles
Review URL: http://codereview.chromium.org/4710001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65453 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This applies only the rename of IPC::ContextMenuParams to
IPC::MiniContextMenuParams so that it doesn't conflict with ::ContextMenuParams
(defined in webkit). This is about half the original patch.
BUG=51409
TEST=compiles
Review URL: http://codereview.chromium.org/4669005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65429 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
via the context menu.
This was because the Back and Forward menu items on the context menu were disabled. The context
menu is displayed by the active document in IE and it attempts to enable/disable these items
based on entries in the IE travel log. The enabling of these items was failing as we were
incorrectly passing in the string id of these options instead of their command id equivalents
Should fix bug http://code.google.com/p/chromium/issues/detail?id=34657
Bug=34657
Test=Covered by new ChromeFrame context menu back forward test.
Review URL: http://codereview.chromium.org/4500002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65231 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit c1c1fed998ee4d839bfe256150e5e59220ebc0ef (r64637).
TBR=nirnimesh@
BUG=51409
TEST=none
Review URL: http://codereview.chromium.org/4194007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64644 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
automation_messages used to live in chrome/test/automation, when it's needed by
browser and chrome_frame. When I started lifting code out of headers and into
implementation files, I was getting link errors and temporarily solved the
problem by compiling the cc files manually into libbrowser.a. Now this is part
of chrome/common/ which is included by all targets needed.
While doing this, discover that automation IPC redefines the ContextMenuParams struct. Rename it to MiniContextMenuParams.
BUG=51409
TEST=none
Review URL: http://codereview.chromium.org/4200007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64637 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Provide event notification for window.close called within
ActiveX and NPAPI. Currently this is handled in ActiveDocument
to close the popups. In ActiveX and NPAPI plugin we just fire
an event as it is upto the container to decide what's the right
thing to do.
BUG=59664
TEST=New tests ChromeFrameTestWithWebServer.FullTabModeIE_WindowClose, ChromeFrameTestWithWebServer.FullTabModeFF_WindowClose
Review URL: http://codereview.chromium.org/4152005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@64092 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
through, either because they were LOG_IF() (which I didn't search for) or they were added during the week I was changing things.
Plus a few misc. cleanup bits.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/4111002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63998 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
base::debug namespace.
This splits apart debug_util into base/debugger and base/stack_trace
There are still two functions in debug_util that I'm not sure what to do with.
Since this uses the base::debug namespace, I removed the functions in
debugger.h from the static class and just made them free functions in the
namespace.
TEST=it compiles
BUG=none
Review URL: http://codereview.chromium.org/3945002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63859 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
old URL.
This would typically occur during redirects or performing back forward operations
when the current and the target URLs were both rendered in ChromeFrame.
A scenario where this would occur is as below:-
1. Navigation to a URL in chrome frame.
2. Clicking on a link which would navigate the current tab to a chrome frame URL.
3. Now hitting back in IE would navigate back. however the address bar would still
display the URL in step 2.
The reason this occurs is step 2 causes a top level navigation in IE via webbrowser::Navigate.
This initiates a navigation sequence which updates the address bar to the URL in step 2.
Eventually we receive navigation updates from chrome where the navigation index is changed due
to a new navigation from step 1 to 2. We end up firing internal navigation events which cause
the IE history to get messed up leading to the problem.
Fix is to only fire internal navigation events if the following are true.
1. navigation indexes are different.
2. urls are different.
3. referrer differs.
4. navigation type is different.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=57207
Bug=57207
Test=Will send out a test in a separate CL. Need to brush up on using accessibility for
link clicks, etc.
Review URL: http://codereview.chromium.org/3988004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63414 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
TEST=it compiles
BUG=none
Review URL: http://codereview.chromium.org/3748012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63216 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
Plus a couple misc. cleanups.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/3850002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@63095 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NPAPI implementation.
These include window.open requests, hrefs with target _blank, etc.
The ChromeFrame NPAPI plugin needs to set the renderer pref which indicates that the host browser
can handle top level requests.
We also pass an additional flag in the CreateExternal tab IPC which indicates whether the host
browser supports full tab mode browsing or not. This defaults to true for IE, as the activex
implementation relies on being able to launch a new window with the attach external tab prefix.
which assumes support for full tab mode for IE being available. If the host browser does not
support full tab browsing the window.open request which comes into the ExternalTabContainer
instance creates a dummy ExternalTabContainer instance which is destroyed when the top level
navigation info is sent back to the host browser.
This CL is a short term fix for the issues with the NPAPI ChromeFrame plugin. Will do some
investigation into a better approach.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=57319
Test=Covered by existing ChromeFrame widget mode tests WidgetModeIE_SrcProperty and
WidgetModeFF_SrcProperty
Fixed incorrect assumptions in the test files used by these tests.
Bug=57319
Review URL: http://codereview.chromium.org/3549006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@61117 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=
TEST=
Review URL: http://codereview.chromium.org/3421029
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60233 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original description:
- added detection of IE9 for ChromeFrame.IEVersion metric
- replaced ChromeFrame.FullTabLaunchType metric with ChromeFrame.LaunchType metric,
which logs more info regarding how it came to be that GCF rendered a page
(but only for the CTransaction patch)
BUG=43885
TEST=none
Review URL: http://codereview.chromium.org/3443017
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@60188 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ChromeFrame rendered
pages. This allows a webpage to put up a confirmation dialog in its beforeunload handler
and potentially cancel the operation. We only support invoking unload handlers on the page
for IE full tab mode. To achieve this the active document handles the OLECMDID_ONUNLOAD
exec command which is passed by the DOCHOST to the object which allows us to potentially
cancel the operation.
Thanks to Stoyan for his help in authoring parts of this CL.
The AutomationMsg_RunUnloadHandlers message which is used only by ChromeFrame is now a sync
message which returns back a bool indicating whether the unload operation can be continued
or not. The ExternalTabContainer now implements the BeforeUnloadFired method in the
TabContentsDelegate and aborts the unload operation if the user chose to not proceed with
the unload.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=33200
Bug=33200
Test=Covered by existing unload event test. Will add a test which validates whether a page
can cancel the unload operation in a subsequent CL.
Review URL: http://codereview.chromium.org/3450014
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59854 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Differences from the above CL include the following:
- RendererPreferences settings for ExtensionHosts are now extracted from the associated_tab_contents(). This ensures that extension hosts will also forward top level navigation requests.
- Instead of explicitly setting the delegate on the TabContents in ExtensionHost::ShowCreatedWindow, instead I instruct the associated tab-contents to add the newly build tab-contents. Note that this is the exact same behaviour performed by TabContents when initiating a top-level navigation to the host browser.
Points of interest:
- See the TODO in navigation_controller.cc. This problem of an unrecognized navigation entry needs further investigation.
- Also, I found that if the ActiveX control is navigated to a chrome-extension URL, then the top-level-navigation will fail because of the format of the URL. The fix was to construct a temporary url in place of the chrome-extension url.
BUG=51091
TEST=None
Review URL: http://codereview.chromium.org/3357013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59142 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ChromeFrame when we
update the navigation state. We now default to SECURELOCK_SET_UNSECURE in case of any auth
errors.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=53649
Bug=53649
Review URL: http://codereview.chromium.org/3345020
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@59128 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(http://codereview.chromium.org/3295019)
The problem is that by allowing ActiveX controls to hook top-level requests, the redirect in the ChromeFrameTestWithWebServer.WidgetModeIE_SrcProperty was being forwarded to the host browser in IE8.
BUG=54920
TEST=ChromeFrameTestWithWebServer.WidgetModeIE_SrcProperty
TBR=ananta
Review URL: http://codereview.chromium.org/3325019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58950 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the host browser with a ChromeFrame instance. If a ChromeFrame instance was loaded with a given profile, the bho used to always forward top-level navigation requests to a CF full-tab instance using the default (iexplore) profile. This caused problems with the automation channel, and the navigation would not complete.
I also cleaned up the gcf and host networking registry keys used by Chrome-Frame so that ActiveX instances will also respect their values.
TEST=None
BUG=None
Review URL: http://codereview.chromium.org/3295019
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58884 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
BUG=54345
TEST=gcf:http://www.google.com should not work by default
and should work only if 'AllowUnsafeURLs' is set to a
non-zero value in registry.
Review URL: http://codereview.chromium.org/3365008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58511 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
the *TabCrashReload* tests.
TEST=Run debug versions of *TabCrashReload* tests. There should be no more dchecks.
BUG=none
Review URL: http://codereview.chromium.org/3241008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@58067 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
navigation sequence missing for the second URL loaded as part of the test. We were not firing the BeforeNavigate event for IE6 for navigations initiated by Webkit. This should also fix the Form post back forward tests which were failing on IE6.
TBR=amit
Review URL: http://codereview.chromium.org/3266011
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57963 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(http://codereview.chromium.org/3167040/show)
In IE8, on Vista, when the user deletes their browsing data, the IDeleteBrowsingHistory interface is invoked twice - once in a low integrity process and once in a medium integrity process.
Only the medium integrity process may succeed, but the low integrity process will restart the automation server after failing to connect to it.
Upon invocation by IE, check the integrity level of the current process - if it is low, exit. GetProcessIntegrityLevel was adapted from rlz. A follow-up changeset will modify rlz to use this implementation.
During editing, some unnecessary headers were removed from win_util.h and correspondingly added to win_util.cc and certain clients who were depending on transient includes.
BUG=56212
TEST=Load some pages using Chrome Frame. Close IE. Verify that the Chrome Frame cache has grown and that the accessed domains appear in the history files. Launch IE, load a page using Chrome Frame. Delete Browsing Data. Note that the tab does not crash, that the on-disk cache files shrink, and that the accessed domains no longer appear in the history file
Review URL: http://codereview.chromium.org/3171033
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57567 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
TEST=See bug.
BUG=52894
Review URL: http://codereview.chromium.org/3122041
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@57539 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
some reason
the test shows up as succeeded even though it is failing.
The test fails when the automation client instance is reused, i.e the new page loads in
the same tab. We need to set the ready state of the active document instance to ready
when we reuse the automation client instance.
TBR=amit
Review URL: http://codereview.chromium.org/3117032
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56963 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes all IPC Log methods from wstring to string. All static logging debug
data changed from wchar[] to char[].
Various string conversion/numeric headers no longer need to be included in
ipc_message_utils.h and have been removed (and added in all implementation
files that require them).
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/3159013
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56563 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Further tighten down what URLs can be loaded in Chrome Frame.
Based on the feedback from the security review and code
inspection, restrict about: scheme only to about:blank
and about:version by default. Factor out logic blocking logic
including for URL zone checking so that all ActiveX, ActiveDoc
and NPAPI will follow the same path. As a result we now block
restricted URL zones in NPAPI instance as well.
Another side effect of this refactoring is that the registry
flag, EnableGcfProtocol, is replaced by AllowUnsafeURLs. If
If this flag is set, then all the security related checking
is turned off.
BUG=50741
TEST=By default gcf: works only for about:blank, about:version and
view-source of http and https. Setting AllowUnsafeURLs to a non
zero value should allow any URL be loaded via gcf:
Review URL: http://codereview.chromium.org/3159006
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@56096 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
case and support document refresh or reload.
When chrome crashes, we draw a poor man's sad tab (":-("), so that can clearly be improved.
Another thing is that if the chrome instance that crashed held several navigational entries, then that history is lost.
TEST=There are a couple of tests included, so run those (*TabCrash*) and also verify that when the chrome automation server is killed that we do the right thing. Also check info in bug report.
BUG=25839
Review URL: http://codereview.chromium.org/3061036
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55565 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
View->Zoom. Currently we only support
Zoom in and zoom out as Chrome only supports these zoom levels.
Added an automation IPC message AutomationMsg_SetZoomLevel to set the zoom level in ChromeFrame.
The other change is in the active document in the handling of the attach external tab message. We now honor the
dimensions if any when we Launch the URL. This ensures that any windows opened outside chrome frame also honor these
dimensions.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=36000
Bug=36000
Review URL: http://codereview.chromium.org/3064049
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55494 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/3071012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@55034 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
window having focus. This regressed recently with
the change to fix focus recycling issues in ChromeFrame while switching tabs.
Review URL: http://codereview.chromium.org/3067023
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54596 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
implement the huge IBrowserService2 interface.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/2847071
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54550 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
active document. This is needed to pass
the referrer correctly to chrome.
TBR=amit
Review URL: http://codereview.chromium.org/3080012
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54292 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
maintained GURL members holding the url and
referrer. We can stuff this information into the ChromeFrameLaunchParams member maintained by the client. This
reduces the complexity in the code related to detecting whether we can navigate up front or after chrome initialization.
The ChromeFrame ActiveX now launches the automation server in its implementation of IPersistPropertyBag::Load. This avoids
race conditions between launching the automation server and navigating to it via put_src.
Review URL: http://codereview.chromium.org/3038038
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54284 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
cookies in the outgoing HTTP requests.
To achieve this we no longer issue navigations with the gcf:attach* prefix. We now issue a navigation to the current
page URL with the attach external tab suffix, which indicates that the page is forced into ChromeFrame without making
an actual HTTP request. This ensures that the new IE8 process has access to all HTTP cookies.
We need to patch IInternetProtocol::LockRequest and UnlockRequest to not call the underlying implementations for our
dummy request as this crashes in IE8 in the prebinding code path.
Fixes bug http://b/issue?id=2277519
Added tests for the CanNavigateFullTabMode helper function.
Bug=2277519
Review URL: http://codereview.chromium.org/3051018
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@54019 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and the command id in all cases. We were
detecting MSHTML command ids based on the command id only while ignoring the group which was wrong.
Part of the fix for http://code.google.com/p/chromium/issues/detail?id=24034
Bug=24034
Review URL: http://codereview.chromium.org/2873070
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53699 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
http://codereview.chromium.org/3031009
A different approach to avoid crashes in buggy 3rd party BHOs.This time we're more preceise and only target the buggy components.Behaviour for components that handle browser events correctly, is unchanged even in the presence of buggy DLLs.The core class here is the BuggyBhoTls class and here's the comment for that class:
// Construct an instance of this class on the stack when firing web browser
// events that can be sent to buggy BHOs. This class will intercept those
// BHOs (see list in cc file) and ignore notifications to those components
// for as long as the BuggyBhoTls instance on the stack lives.
TEST=A better fix for bug 44463 but also fixes bug 49373 and a number of crashes that haven't been associated with bug reports yet.
BUG=44463, 49373
Review URL: http://codereview.chromium.org/3053008
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53236 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
happens whenever a tab rendering a chrome frame
page receives focus by switching to it. Whenever we receive focus in ChromeFrame we send over an IPC to set the initial
focus to Chrome. In this IPc we invoke the FocusThroughTabTraversal function on the TabContents which basically cycles
through the focus on the page which is not correct for full tab mode.
Fix is to handle the WM_SETFOCUS message in the active document and invoke the GiveFocusToChrome with false indicating
that we don't want to invoke the FocusThroughTabTraversal function which cycles through the view. It is sufficient to
set focus to the tab.
We also handle the WM_SHOWWINDOW message in the active document and set focus to the document if it is visible. This
ensures that the page gets focused correctly.
Fixes bug http://code.google.com/p/chromium/issues/detail?id=48459
Fixes bug http://code.google.com/p/chromium/issues/detail?id=25890
Bug=48459, 25890
Review URL: http://codereview.chromium.org/2825061
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53206 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
BHOs.This time we're more preceise and only target the buggy components.Behaviour for components that handle browser events correctly, is unchanged even in the presence of buggy DLLs.The core class here is the BuggyBhoTls class and here's the comment for that class:
// Construct an instance of this class on the stack when firing web browser
// events that can be sent to buggy BHOs. This class will intercept those
// BHOs (see list in cc file) and ignore notifications to those components
// for as long as the BuggyBhoTls instance on the stack lives.
TEST=A better fix for bug 44463 but also fixes bug 49373 and a number of crashes that haven't been associated with bug reports yet.
BUG=44463, 49373
Review URL: http://codereview.chromium.org/3031009
TBR=tommi@chromium.org
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@53197 0039d316-1c4b-4281-b951-d872f2087c98
|