| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This involved adding a new method on WebViewDelegate to allow the embedder to
intercept data being loaded for a document.
I also had to plumb a few more FrameLoaderClient notifications through
WebViewDelegate. See DidReceiveResponse and DidFinishLoading.
R=tony
BUG=15648
TEST=covered by errorpage_uitest.cc
Review URL: http://codereview.chromium.org/160578
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@22389 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inserted for LTR systems
To avoid empty square displayed around tooltip when system does not have RTL support, only add Unicode marks when element's directionality is not the same as UI's directionality.
Note:
1. tooltip will be displayed using its element's directionality.
2. in system without RTL support, tooltip will only be displayed correctly (in its element's directionality and without empty square around) when both UI and element's directionality is LTR.
BUG=http://crbug.com/17468
TEST=
1. Uninstall the right-to-left script and east Asian script through the Control Panel and restart system.
2. Run English Chrome.
3. given the following HTML, the displayed tooltip should not have empty square around.
<html>
<head>
<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="TEXT/HTML; CHARSET=utf-8">
</head>
<body>
<span style="background-color:Blue" title="Hi!">And now here!</span>
</body></html>
Review URL: http://codereview.chromium.org/160262
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21975 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
context menus.
Also renamed ContextNodeType per fishd's suggestion.
BUG=15686
TEST=none
Review URL: http://codereview.chromium.org/155954
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@21466 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/149789
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20932 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
| |
This code should enable the creation of a basic context menu for the Video and Audio tags. The actions for fullscreen, save screenshot, loop, and set playback rate are not yet implemented.
BUG=15686
TEST=None
Review URL: http://codereview.chromium.org/149604
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20931 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/149744
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20859 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/155621
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20855 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
use of WebKitClient (replacing WebWidgetDelegate from glue).
The ripple effects of this change are rather large, but most
of the impact is mechanical.
The more interesting changes include:
1- Removing the WebWidget parameter from WebWidgetClient methods. This didn't
matter at all to RenderWidget or RenderView, but it did cause some changes to
be made to TestWebViewDelegate. Now, it is not possible to share a delegate
implementation for both the WebView and a popup menu, so I have a second
instance of the delegate owned by TestShell for use with popup menus.
2- Plumbing WebNavigationPolicy in place of WindowOpenDisposition was getting
to be a pretty large change, so I stopped short of deleting WindowOpenDisposition.
That way the Chrome side can remain mostly unmodified. I then added a mapping
function to convert from WebNavigationPolicy to WindowOpenDisposition.
3- The IME methods on WebWidget were renamed (reviewed separately by hbono), and
there is now an enum to specify the composition command (WebCompositionCommand).
4- I added IPC serialization for WebCompositionCommand and WebTextDirection,
which cleaned up some code that was just using ints in IPC messages.
R=jam
BUG=16234
TEST=none
Review URL: http://codereview.chromium.org/149620
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20854 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds registration of content scripts, parented to a frame's
context. When a frame's context goes away, we unregister it and any content
script contexts for it.
There's a corresponding webkit change that lets us know when a content script
context is created. Filed upstream as
https://bugs.webkit.org/show_bug.cgi?id=27104.
BUG=16228
TEST=install an extension with a content script that communicates with a parent
process. Messages should be sendable both ways.
Review URL: http://codereview.chromium.org/155309
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20677 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
make use of WebPopupMenuInfo from the WebKit API. WebMenuItem
remains in webkit/glue for convenience with IPC marshalling and
related usage in Chrome.
This work is precursor to switching over to using WebWidget from
the WebKit API.
BUG=16234
TEST=html select drop downs should still work on the mac. try
switching languages on news.google.com.
R=paul
Review URL: http://codereview.chromium.org/155378
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@20624 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, windowed plugins are parented in a two-stage process: initially,
the plugin is parented to the render view, then later it's reparented to
a special per-plugin window.
On Linux, plugin embedding always needs a special per-plugin window before
it can be initialized. So there's no way to do the two-stage initialization
process, and we only want to construct the browser-side plugin container for
windowed plugins after the plugin requests it.
Plumbing this through the WebPlugin interface will also allow us to side-route
this request for window creation out to the browser process in the
multi-process case.
BUG=15421
TEST=plugins still work in test_shell
Review URL: http://codereview.chromium.org/150034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19602 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
Windows.
Review URL: http://codereview.chromium.org/150088
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19573 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On Windows, windowed plugins are parented in a two-stage process: initially,
the plugin is parented to the render view, then later it's reparented to
a special per-plugin window.
On Linux, plugin embedding always needs a special per-plugin window before
it can be initialized. So there's no way to do the two-stage initialization
process, and we only want to construct the browser-side plugin container for
windowed plugins after the plugin requests it.
Plumbing this through the WebPlugin interface will also allow us to side-route
this request for window creation out to the browser process in the
multi-process case.
BUG=15421
TEST=plugins still work in test_shell
Review URL: http://codereview.chromium.org/150034
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19560 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
WillDestroyWindow is already plumbed over to the browser process in the
multiproc case; we want to plumb it to our RenderView delegate so we
can do similar cleanup in test_shell.
BUG=15423
Review URL: http://codereview.chromium.org/147251
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19475 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A recent change broke the load times. It also revealed some deficiencies.
This adds a new time marker for when a load is committed, which is
a more interesting value than the start of the load (which we still keep).
Also, the first layout time wasn't an interesting time to keep, instead
we keep the time of the first paint.
The histograms were modified to use the new values when appropriate.
Review URL: http://codereview.chromium.org/149099
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19465 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
BUG=no
TEST=no
Review URL: http://codereview.chromium.org/147124
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19424 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
tbr=darin
Review URL: http://codereview.chromium.org/149081
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19368 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a new time marker for when a load is committed, which is
a more interesting value than the start of the load (which we still keep).
Also, the first layout time wasn't an interesting time to keep, instead
we keep the time of the first paint.
The histograms were modified to use the new values when appropriate.
Review URL: http://codereview.chromium.org/147123
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19361 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/146027
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@19108 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
files in webkit/api.
Here's the mapping:
webkit/glue/webdatasource.h -> webkit/api/public/WebDataSource.h
webkit/glue/weberror.h -> webkit/api/public/WebURLError.h
webkit/glue/weburlrequest.h -> webkit/api/public/WebURLRequest.h
webkit/glue/webresponse.h -> webkit/api/public/WebURLResponse.h
I kept the implementation of WebDataSource in webkit/glue for now because it
helps to have it close to WebFrameImpl and WebFrameLoaderClient.
To facilitate this change, I needed to make use of WrappedResourceRequest and
WrappedResourceResponse from webkit/api/src within the implementation files of
webkit/glue. This is only a temporary usage of webkit/api/src from the
outside. It will go away when WebFrame, etc. get moved into webkit/api.
I modified these wrapper classes to expose the 'bind' function so that I can
re-bind a wrapper. This is used in WebDataSourceImpl::request() and related
methods to allow the interface to return a const reference to a WebURLRequest
and WebURLResponse.
The changes here are fairly mechanical. I'm not too happy about the way
WebDataSource::redirectChain now works. I would prefer a solution that didn't
involve so much copying, but I'm not going to worry about optimizing that now.
R=brettw
BUG=10041
TEST=none
Review URL: http://codereview.chromium.org/126286
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18747 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Move PasswordForm into the webkit_glue namespace.
TEST=none
BUG=10041
R=brettw
Review URL: http://codereview.chromium.org/126190
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18515 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of having WebFrameImpl generate SearchableFormData, PasswordForm, and AutofillForm classes, allow the embedder (RenderView) to do so.
This is done to help minimize the dependencies WebFrameImpl has on other code, which will make it easier to move WebFrame and WebDataSource into the WebKit API.
Most significant change: Now, RenderView always sets a NavigationState on WebDataSource instances. We used to only do so for browser initiated navigations. This is done so that we can store things like SearchableFormData and friends on the NavigationState.
To facilitate this change, it was necessary to add a way through the WebKit API to refer to a HTMLFormElement. This CL introduces WebForm, which is like a RefPtr<HTMLFormElement>, so you can just copy a WebForm around by value and the right thing happens.
Some of the other changes are about moving more things into the webkit_glue namespace. On hindsight, I probably should have done that as a separate CL.
BUG=10041
TEST=none
R=brettw
Review URL: http://codereview.chromium.org/126083
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18395 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/126054
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18304 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a work in progress draft.
Summary of changes:
1. Moved code shared by chrome and test_shell to webkie/glue:
WebMediaPlayerImpl
SimpleDataSource
VideoRendererImpl
2. Since WebMediaPlayerImpl is shared, chrome specific renderers
are enabled by passing the FilterFactoryCollection into
WebMediaPlayerImpl, this is done in RenderView. And
WebMediaPlayerImpl provides some default renderer filters,
which are used by the test shell and also chrome.
Review URL: http://codereview.chromium.org/119229
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18182 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
from the currently loaded site. We are careful in this patch to
continue to allow dropping URLs in text fields within the app
window, and behavior for normal browser windows remains as
before.
There is a slight glitch when dragging a to an app window on the
border of the window. Even though it is very brief, it is still
disturbing.
BUG=7171
TEST=Open Chrome (1), load google.com. Open Chrome (2), load
yahoo.com. Drag a link from 1 to 2 and a link from 2 to 1 (both
allowed). Create an app shortcut from 1, drag a link from 1 to
2 (allowed) and a link from 2 to 1 (denied). Verify that link
scan be dragged to the omnibox and to text fields.
Patch by Chase Phillips <chase@chromium.org> via
http://codereview.chromium.org/119298
Review URL: http://codereview.chromium.org/121003
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18100 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
line --auto-spell-correct, "IMB" should not change to "IBM"
Review URL: http://codereview.chromium.org/119210
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@18099 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL implements InspectorClient's API for reading / writing inspector settings. Here is how this is done:
- inspector_client_impl.cc caches / serializes preferences into raw strings. It supports all kinds of settings except for string vector. I did not implement it since a) it requires more escaping b) I think we should get rid of it upstream. It then passes serialized settings string over IPC.
- There is a dedicated IPC message called UpdateInspectorSettings that takes care of settings update.
Two things I don't like:
1) reading settings and writing settings follow different paths: WebPreferences interface for read, delegate -> IPC for write. WebPreferences on read is used since these settings are needed very early in the page cycle. delegate -> IPC on write is the only option.
2) this looks like too much code on the Chrome side for functionality like this. Is there a more generic way of settings and persisting WebKit's preferences in Chrome? Should there be one?
Review URL: http://codereview.chromium.org/119041
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17473 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
- reduce header dependencies
- remove redundant forward declarations
Review URL: http://codereview.chromium.org/115871
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@17313 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds a DidCreateDataSource method to WebViewDelegate,
which the embedder uses to know if their LoadRequest
resulted in a navigation. The embedder then associates the
ExtraData with the WebDataSource at that point. The
WebDataSource then proceeds to be treated as the provisional
data source, possibly failing or being committed. We then
inspect WebFrame::GetDataSource in DidCommitLoadForFrame to
recover the ExtraData.
We have to take care to handle reference fragment
navigations since those do not result in a new WebDataSource
being created. So, in DidChangeLocationWithinPage, we
update the ExtraData associated with the WebDataSource
returned by WebFrame::GetDataSource.
One thing that is important to note: In
DidCommitLoadForFrame, we would previously always inspect
the value of GetDataSource returned from the main frame
instead of looking at the frame passed to
DidCommitLoadForFrame. This explains why WebFrameImpl::
LoadRequest needed to cached ExtraData on the current
WebDataSource, and I think doing so is awkward and wrong.
My change is to always store the ExtraData on the first
WebDataSource to be created as a result of LoadRequest.
Then in DidCommitLoadForFrame, I always inspect the
ExtraData from the given WebFrame. This means that for
history navigations that only navigate a subframe, we'll end
up with ExtraData associated with the WebDataSource of a
subframe. I think this is OK even though the old code was
trying to avoid this scenario. See the DCHECK removed in
RenderView::UpdateURL.
BUG=11423
R=brettw
Review URL: http://codereview.chromium.org/115575
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16580 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
of assistive technologies (accessibility). Also cleans up the handling of WM_GETOBJECT in RenderWidgetHostViewWin and WidgetWin, as well as in BrowserAccessibilityManager.
Review URL: http://codereview.chromium.org/115374
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@16449 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally reviewed at http://codereview.chromium.org/100353
Eliminate webkit/glue/webhistoryitem* in favor of adding a
NavigateBackForwardSoon method WebViewDelegate. This moves
all of the hacky details of how we intercept "history.{back,
forward,go}" into the webkit layer. My eventual plan is to
teach WebCore how to make this not hacky.
In this version of the CL, TestWebViewDelegate performs the
back/forward navigation directly in NavigateBackForwardSoon
instead of using PostTask to delay it. I'm doing this to
minimize regressions so that I can hopefully get the rest of
this CL landed.
I also already made the changes to WebKit to force history.
{back,forward,go} to be processed asynchronously.
Finally, it was necessary to move DumpBackForwardList out of
webkit_glue.cc since it was using itemAtIndex to generate
those results, and now that we return synthetic URLs for
that function, the results were very wrong. The fix is to
move DumpBackForwardList into TestShell so that it can more
directly inspect the TestNavigationController. Now, it is
necessary for webkit_glue.h to expose a function to dump
a content state string (aka a WebCore::HistoryItem).
BUG=11423
R=mpcomplete
Review URL: http://codereview.chromium.org/113328
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15997 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
TBR=mpcomplete
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15942 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Originally reviewed at http://codereview.chromium.org/100353
Eliminate webkit/glue/webhistoryitem* in favor of adding a
NavigateBackForwardSoon method WebViewDelegate. This moves
all of the hacky details of how we intercept "history.{back,
forward,go}" into the webkit layer. My eventual plan is to
teach WebCore how to make this not hacky.
In this version of the CL, TestWebViewDelegate performs the
back/forward navigation directly in NavigateBackForwardSoon
instead of using PostTask to delay it. I'm doing this to
minimize regressions so that I can hopefully get the rest of
this CL landed.
I also already made the changes to WebKit to force history.
{back,forward,go} to be processed asynchronously.
BUG=11423
TBR=mpcomplete
Review URL: http://codereview.chromium.org/115288
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15940 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
| |
Issue=7624
Review URL: http://codereview.chromium.org/42608
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15888 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
| |
Highlights:
1. WebCore::MediaPlayerPrivate now only has one static method that constructs WebMediaPlayerClient
2. Implementation of WebCore::MediaPlayerPrivateInterface now is WebMediaPlayerClient
3. WebMediaPlayerClient does the delgation to WebMediaPlayer
4. Implemtnation of real media player will go into chrome/renderer and implements WebMediaPlayer
Review URL: http://codereview.chromium.org/105007
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15492 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
for anything; it will be used for whitelisting popups by hostname.
BUG=11440
Review URL: http://codereview.chromium.org/105004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15326 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
TBR=mpcomplete
Review URL: http://codereview.chromium.org/108005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15279 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
shell_ being null. Moved the RevokeDragDrop call to the
TestShell destructor instead.
Eliminate webkit/glue/webhistoryitem* in favor of adding a
NavigateBackForwardSoon method WebViewDelegate. This moves
all of the hacky details of how we intercept "history.{back,
forward,go}" into the webkit layer. My eventual plan is to
teach WebCore how to make this not hacky.
BUG=11423
R=mpcomplete
Review URL: http://codereview.chromium.org/108004
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15278 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
* Fix an 80-column issue
* Remove an unused param
* Remove an unnecessary setter
* Fix a variable capitalization style violation
Review URL: http://codereview.chromium.org/100361
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15254 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
TBR=mpcomplete
Review URL: http://codereview.chromium.org/99370
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15246 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
NavigateBackForwardSoon method WebViewDelegate. This moves
all of the hacky details of how we intercept "history.{back,
forward,go}" into the webkit layer. My eventual plan is to
teach WebCore how to make this not hacky.
BUG=11423
R=mpcomplete
Review URL: http://codereview.chromium.org/100353
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15244 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
| |
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15230 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gets called from WebFrameLoaderClient::frameLoaderDestroyed().
The Chromium Embedded Framework needs this notification to properly clean up
memory associated with specific WebFrame instances (for example, custom
NPObject types bound to the WebFrame via BindToWindowObject()).
This patch was contributed by Marshall Greenblatt.
R=aa,darin
Review: http://codereview.chromium.org/99283
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15223 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for file download via context-menu.
For a download initiated with a click on a link in a web page, a webkit-side change is necessary, which will be done later.
Add a field (referrer_charset) to URLRequestContext and DownloadCreateInfo. It's set to the character encoding of a document where the download request originates from when it's known (download initiated via "save as" in the context menu).
If it's not known (a download initiated by clicking on a download link or typing a url directly to the omnibox), it's initialized to the default character encoding in the user's preference. I guess this is marginally better than leaving it empty (in that case, step 2b below will be skipped and step 2c will be taken) because a user has a better control over how raw 8bit characters in C-D are interpreted (especially on Windows where a reboot is required to change the OS default codepage).
This is later passed to GetSuggestedFilename and used as one of fallback encodings (1. UTF-8, 2. origin_charset, 3. default OS codepage). With this change, we support the following:
1. RFC 2047
2. Raw-8bit-characters : a. UTF-8, b. origin_charset, c. default os codepage.
3. %-escaped UTF-8.
In this CL, for #3, I didn't add a fallback similar to one used for #2. If necessary, it can be added easily. New entries are added to 3 existing tests. What's previously not covered (raw 8bit Content-Disposition header) is now covered in all 3 tests.
BUG=1148
TEST=net unit test: NetUtilTest.GetFileNameFromCD
NetUtilTest.GetSuggestedFilename
unittest : DownloadManagerTest.TestDownloadFilename
Review URL: http://codereview.chromium.org/83002
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@15113 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
| |
BUG=10927
Review URL: http://codereview.chromium.org/93104
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14517 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
| |
BUG=10995
R=jam
Review URL: http://codereview.chromium.org/92144
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14461 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
| |
Review URL: http://codereview.chromium.org/93042
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14402 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
that should really just be public methods on TestWebViewDelegate.
R=dglazkov
Review URL: http://codereview.chromium.org/79080
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@14008 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
| |
amenable to cross-platform implementation.
BUG=9852
Review URL: http://codereview.chromium.org/63093
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13573 0039d316-1c4b-4281-b951-d872f2087c98
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
layer interface. This will help when we move those interfaces into
the WebKit API.
This is a second attempt at r13381, which was already reviewed here:
http://codereview.chromium.org/63126
The only change between that CL and this one is in render_view.h, where I
needed to change a parameter type from gfx::Rect to WebRect.
TBR=dglazkov
Review URL: http://codereview.chromium.org/64005
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@13424 0039d316-1c4b-4281-b951-d872f2087c98
|