| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=automated testing should suffice
R=ananta@chromium.org,robertshield@chromium.org
Review URL: http://codereview.chromium.org/7276037
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@90914 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
don't implement
the NPAPI redirect notification spec.
We compare the URL received in the NewStream notification with the requested URL and if they
differ we cancel the current request and inform Chrome that this was a redirect. The sideeffect
would be that there would be two GET requests sent out.
BUG=69419
TEST=none.
Review URL: http://codereview.chromium.org/6381005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@72029 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
notifications. This
is basically implementing the NPP_URLRedirectNotify plugin function and invoking the browser
end function NPN_URLRedirectResponse indicating whether the redirect is to be followed or
not.
The ChromeFrame NPAPI implementation always disallows url redirects from the plugin and
instead expects Chrome to follow the redirect.
Tested this with a Firefox 4 nightly build. Currently this does not work as expected because
of a bug in Firefox where it invokes the NPP_URLRedirectNotify function with the original
URL instead of the redirected URL. This is tracked by mozilla bug https://bugzilla.mozilla.org/show_bug.cgi?id=625164
BUG=69419
TEST=none. Will add a test for this once we have a builder with a working version of Firefox 4.
Review URL: http://codereview.chromium.org/6223003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@71271 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the version mismatch warning dialog. Used this in ceee/ to only show
it once per tab.
Changed the logic in Firefox to show the warning dialog even when
in privileged mode. This will mean it gets shown once per Firefox
window.
Wrote a unit test for the additional logic in ChromeFrameActivex.
To write the unit test, used com_mock.py to generate a mock of
the IChromeFramePrivileged interface. This can be extended to
generate mocks of the other CF interfaces.
Discovered duplication of np_browser_functions.h and .cc, resolved
this to a single copy (the one under chrome_frame).
Changed things around so chrome_tab.idl is built only once; this
also lets me more easily depend on it in the com_mock rule.
BUG=none
TEST=chrome_frame_unittests.exe
Review URL: http://codereview.chromium.org/4563001
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@65613 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
TEST=none
BUG=none
Review URL: http://codereview.chromium.org/1727021
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@46175 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
needs to be
updated since it currently depends on APIs that have been deprecated. The
new method for determining if CF is running in privilege mode is to verify that
the URL of the page that instantiates CF is a "chrome:" URL.
An advantage to this change is the code should now work in all version of
Firefox. Previously, the code was different for each of versions 3.0, 3.5, and
now 3.6.
Note that the API change to npapi::GetStringIdentifiers() was necessary to get
around a problem where xpcom defines the same typedefs as chrome base, but with
different types. If there is a better solution, please let me know.
TEST=see existing unit tests
BUG=none
Review URL: http://codereview.chromium.org/1535002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@43311 0039d316-1c4b-4281-b951-d872f2087c98
|
|
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
|