The canonical bug format is TODO(crbug.com/<id>). TODOs of the
following forms will all be migrated to the new format:
- TODO(crbug.com/<old id>)
- TODO(https://crbug.com/<old id>)
- TODO(crbug/<old id>)
- TODO(crbug/monorail/<old id>)
- TODO(<old id>)
- TODO(issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/<old id>)
- TODO(https://issues.chromium.org/u/1/issues/<old id>)
- TODO(bugs.chromium.org/<old id>)
Bug id mapping is sourced from go/chrome-on-buganizer-prod-issues.
See go/crbug-todo-migration for details.
#crbug-todo-migration
Bug: b/321899722
Change-Id: Iee14d10d544e9f0ec046117cc4ec8a55c427adc0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469947
Reviewed-by: Darryl James <dljames@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1290838}
When the code was originally written, "mouse lock" was a popular term in
the gaming industry and the PointerLock API didn't even exist. Now that
"pointer lock" is an established term, we are switching our codebase
away from the old term to be consistent with the web platform API:
https://developer.mozilla.org/en-US/docs/Web/API/Pointer_Lock_API
There still are some names that aren't renamed in this CL, e.g. enum
values recorded in metrics.
There should be no behavioral changes.
Low-Coverage-Reason: TRIVIAL_CHANGE This is a rename CL
Bug: 1518948
Change-Id: Ib66d87e4919c2570109d7e6755ea91dfc18d42fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5148491
Commit-Queue: Takumi Fujimoto <takumif@chromium.org>
Reviewed-by: Dmitry Gozman <dgozman@chromium.org>
Reviewed-by: Mustaq Ahmed <mustaq@chromium.org>
Reviewed-by: Vincent Scheib <scheib@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Finnur Thorarinsson <finnur@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1251864}
WebPreferences::navigate_on_drag_drop and
RendererPreferences::can_accept_load_drops attempted to implement the
same functionality, which is to disable navigation via drag n drop of a
URI. The WebPreferences version didn't work as well because it only
blocked the navigation inside the web contents, but still managed
to allow a new tab to be opened to about:blank#blocked, and did not
affect the drag operation calculation (which affects the displayed
cursor and affects event routing). Thus, the WebPreferences version is
deleted and its only client, which is BrowserPluginGuest, is updated
to use the RendererPreferences setting.
Bug: 1475698,733996
Change-Id: Ifa8592cc754632b17e3434dea7284c7b06f5ba11
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4809488
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Commit-Queue: Evan Stade <estade@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1188058}
This refactoring is a part of bigger project to handle input on viz
thread (go/input-on-viz). We are moving input related interfaces that
RenderWidgetHostImpl uses to //content/common/input. This would provide
a single stack in //content/common/input that we quickly enter in either
the browser or GPU viz which would allow for relatively clean movement
of code. GPU process can link in the same input stack and forward the
data to the renderer using the same code. This change also renames
skip_in_browser to skip_if_unhandled.
AX-Relnotes: n/a
Bug: 1472313, b/294817120
Change-Id: I80ebdb6c8421392ae507c01a1f4269d1c9100ddc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4758689
Reviewed-by: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Commit-Queue: Aman Verma <amanvr@google.com>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1185117}
In the case where a webview creates a popup window, the opener web
contents temporarily owns the new guest web contents between the
renderer creating and showing the window. If the opener is destroyed at
this time, the new guest (WebViewGuest) is destroyed as well. Due to
the ordering of the destruction of the new guest web contents, it may
attempt to access the destroyed WebViewGuest through the delegate
interface. We now access this delegate through a weak ptr.
Low-Coverage-Reason: NOTREACHED
Bug: 1442516
Change-Id: I417431ad487bc9db0551c1e0363379c5ff455d59
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4515455
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1141602}
It is currently possible for GetParentOrOuterDocument(OrEmbedder)
to return null despite being owned by an outer frame tree. This is due
to unattached guest views (due to newwindow event usage) and the
orphaned state for portals. In (almost) all cases, callers want the
owner to be returned even though it has not technically been embedded
yet.
We now have these methods iterate through the "prospective" outer
document, referring to the RenderFrameHost that will embed the frame
tree (e.g. for orphaned portals, it's simply the RFH that owns the
portal).
We now expose GetParentOrOuterDocumentOrEmbedder and
GetOutermostMainFrameOrEmbedder for the content public API. This CL
includes a non-test illustrative use of each outside content. Further
conversions are tracked by issue 1257277.
The cases which do need to handle this edge case separately are
RenderWidgetHostView iteration and accessibility, for which we retain
the existing iteration behaviour internal to content.
This change largely removes the need for
WebContents::GetResponsibleWebContents. We keep it for now, as a
convenience method around GetOutermostMainFrameOrEmbedder and remove
the WebContentsDelegate::GetResponsibleWebContents that was previously
used to implement this.
Bug: 1257276, 1257277, 1325850
Change-Id: I3ad9c17d76c6b02284d4090f5b45e4983e28a10b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4234409
Reviewed-by: Dominic Battré <battre@chromium.org>
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1106818}
This patch is a no-op with all the common build flags.
Add the "DanglingUntriaged" raw_ptr annotation. It indicates a raw_ptr
becomes dangling, and it should be triaged/fixed. This will also disable
dangling protection for those pointers, once enabled.
These were identified by running the linux-lacros-rel CQ bot with DPD
activated (both build + runtime here: https://crrev.com/c/3941825)
Bug: 1291138
Change-Id: Id00ef560214bcc3ce1e38fd97e84f1e733586703
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4027920
Commit-Queue: Ali Hijazi <ahijazi@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Owners-Override: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1072127}
This patch must be a no-op with all the common build flags.
Add the "DanglingUntriaged" raw_ptr annotation. It indicates a
raw_ptr becomes dangling, and it should be triaged/fixed. This will also disable dangling protection for those pointers, once enabled.
These were identified by running the CQ bots with DPD activated (both build + runtime here: https://crrev.com/c/3941825)
Bug: 1291138
Change-Id: I07e3d85b1c629f7d49c928f1fca42a538c64ef3b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3959615
Owners-Override: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Pâris Meuleman <pmeuleman@chromium.org>
Commit-Queue: Ali Hijazi <ahijazi@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1061867}
SendTextInputTypeChangedToView has been dead since this class stopped
handling focus changes, so we remove that.
There's no code path that would cause this class to be initialized
multiple times, so we remove the code that handles this.
We remove stale comments referring to legacy IPC handling, a
renderer side BrowserPlugin, and an assumption of no cross-process
navigations.
Bug: 533069
Change-Id: I98c4504ee01e9a044a4827fd3348673448fe8e3f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3871498
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1043453}
This interface no longer appears needed. It only has one remaining
method, WillDestroy which (1) resets focus to the embedder if the
inner contents being destroyed has focus, and (2) clears a raw
pointer to the owner WebContents in BrowserPluginGuest.
(1) is redundant as an inner WebContents being destroyed already
releases focus on its own in ~WebContentsImpl.
(2) doesn't seem like an issue since it's being destroyed anyway, but we
take this opportunity to remove the only case of this being
asynchronously dereferenced. Relatedly, we also remove some duplication
of code in BrowserPluginPopupMenuHelper and correct usage of
coordinate transformation functions.
Bug: 533069, 1267977
Change-Id: Idedcbd490d886d72c7b623539a27137faa624fc1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3866440
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1042357}
There are no changes to a guest's lifetime management needed to achieve
this. This code path was already mostly using unique_ptr. We just need
to plumb the unique_ptr through some functions instead of releasing it
and transferring back into a unique_ptr.
Bug: 832879, 1261928
Change-Id: I8971f5d92d82aeb21e3b0a0b1c5bff8028fc1296
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3847070
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1038994}
This reapplies the rewrite_raw_ptr_fields rewriter on Mac platform.
This change is a merge of the following changes:
PS1 raw_ptr rewrite generated by
rewrite-multiple-platforms.sh mac
on 7227cf9d6c
PS2 Unrewrite and exclude field that is used as reference with AutoReset on non-mac platforms
PS3 Fix compile errors caused by NULL
PS4 Unrewrite and exclude pointer to Objective-C object
PS5 Rebase
PS6 Unrewrite and exclude pointer to Objective-C object
PS7 Fix compile errors caused by NULL
PS8 Format code
AX-Relnotes: n/a.
Bug: 1073933
Change-Id: I1154ea591397ec0eeef4eeea9fea84eeeb14fff6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3720981
Owners-Override: Bartek Nowierski <bartekn@chromium.org>
Reviewed-by: Bartek Nowierski <bartekn@chromium.org>
Owners-Override: Keishi Hattori <keishi@chromium.org>
Commit-Queue: Keishi Hattori <keishi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1017853}
The active state was incorrect for child RenderViews of a frame tree
because it was not replicated across the entire page. Ensure that the
active state is indeed replicated.
To accomplish this correctly change RenderWidgetHostViewAura/Mac to
let the WebContentsImpl know about replicating the active state.
RenderWidgetHostViewAndroid does not yet have support for non-active
windows (it would need to be added for Android multi-window support
and likely hook into the onTopActivityResumedChanged) so whenever a
frame receives focus it becomes active. This support is unchanged.
Add is_active to the InputHandler IPC (via compositor thread) because
this can race against the SetActive IPC which is associated with the
legacy IPC channel.
Augment a RenderWidgetHostViewAura test to ensure that a cross site
iframe child has its active state set correctly.
BUG=1313121
Change-Id: I3932147eccd97bbd256d1c0161d8366f781ffdf8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3570062
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Charlie Reis <creis@chromium.org>
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#990585}
The enum is defined but only handled in some files for Lacros. This
appears to have been an oversight. This CL fixes all callsites to have
the same behavior for ash and lacros.
Bug: 1235874
Change-Id: Ibe3f3b9c19ac292e162230bc1ddb628082996028
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3269048
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Nico Weber <thakis@chromium.org>
Commit-Queue: Erik Chen <erikchen@chromium.org>
Cr-Commit-Position: refs/heads/main@{#946647}
This inlines all remaining DISALLOW_* macros in content/. This is done
manually (vim regex + manually finding insertion position).
IWYU cleanup is left as a separate pass that is easier when these macros
go away.
Bug: 1010217
Change-Id: I8b5ea6dd9f8a3f584cf3eef82634017a38b15be8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3193883
Commit-Queue: Peter Boström <pbos@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#936160}
This replaces DISALLOW_COPY_AND_ASSIGN with explicit constructor deletes
where a local script is able to detect its insertion place (~Foo() is
public => insert before this line).
This is incomplete as not all classes have a public ~Foo() declared, so
not all DISALLOW_COPY_AND_ASSIGN occurrences are replaced.
IWYU cleanup is left as a separate pass that is easier when these macros
go away.
Bug: 1010217
Change-Id: Iea478401b7580682c7b9f195f7af9cbbdb6ce315
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3167292
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#923194}
As part of the SiteInstanceGroup refactoring, RenderViewHost will be
associated with a group of SiteInstances instead of a single
SiteInstance or SiteInfo.
To support this, this CL removes one use of
RenderViewHostImpl::site_info_ for determining if the RenderViewHost is
in a guest. That can be queried from the delegate, similar to IsPortal.
This should result in no behavior change, since IsGuest should be
consistent across all SiteInstances of a WebContents.
Bug: 1166021
Change-Id: Ic466cb5fe7ac2e7bcade24342a2fe759b5dee255
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2845894
Reviewed-by: W. James MacLean <wjmaclean@chromium.org>
Commit-Queue: Charlie Reis <creis@chromium.org>
Cr-Commit-Position: refs/heads/master@{#876763}
The WebContentsObserver header is in content/public/ so it should not
expose content/-internal types. It does not need to do so, since the
implementation can cast to WebContentsImpl there. Also, the friend
declaration (in the private section of the class) does not require a
forward declaration.
R=creis@chromium.org
Change-Id: Ica48fd34d35f1ca91beb290e0f82adc88f2e5235
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2737058
Reviewed-by: Charlie Reis <creis@chromium.org>
Commit-Queue: danakj <danakj@chromium.org>
Cr-Commit-Position: refs/heads/master@{#860243}
There is still some drag and drop code in BrowserPlugin classes. This
code is all either dead or a no-op, which we now remove.
There is also some drag and drop test supporting code that is no longer
invoked by any test, which we also remove.
Note that via manual testing, drag and drop of links over a webview
continues to have no effect, and drag and drop of draggable elements
continues to work.
Bug: 533069
Change-Id: Ie9291306eff1d5f2d92c8f7c1917d6a8dbfa5d86
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2562784
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#832925}
The change is mostly mechanical replacing defined(OS_CHROMEOS) with
BUILDFLAG(IS_CHROMEOS_ASH) and GN variable is_chromeos with
is_chromeos_ash with some special cases (For those cases please
refer to http://go/lacros-macros).
The patch is made in preparation to switching lacros build from
target_os=linux to target_os=chromeos. This will prevent lacros from
changing behaviour after the switch.
Bug: 1052397
Change-Id: Ieb265e116ff6ada5e2f99d609ff12fb9f92727e0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2534271
Commit-Queue: Yuta Hijikata <ythjkt@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#829687}
DragMsgStart_TargetDragEnter becomes DragTargetDragEnter on the widget
mojo interface. DragHostMsg_UpdateDragCursor goes away as it was
just the response to TargetDragEnter. These are the last of the drag
messages using legacy IPC.
Bug: 1039255
Change-Id: Ia030a3dd651bdfe9ac6be2dc8d0fa0a54c77c1ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2448052
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Henrique Ferreiro <hferreiro@igalia.com>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/master@{#821300}
As a precursor to crrev.com/c/2412309, this CL adds a new C++ struct,
along with the relevant mojom traits for typemapping, that will now
be used for IPC between the browser and renderer processes instead
of directly using the blink.mojom.RendererPreferences mojo struct.
This is needed in order to migrate PageMsg_SetRendererPrefs to
Blink (see CL 2412309) since, even thought that message will now
be received and handled inside Blink itself, it's still necessary
to pass it back to //content/renderer as it's still needed in
several places such as RenderView and //content/renderer/loader,
and having the mojom struct only would cause trouble because we
can't simply pass a Blink variant of that struct into //content.
Having this C++ struct and its corresponding typemapping solves this
problem since Blink will no longer receive the Blink variant of the
mojo struct but just a blink::RendererPreferences, which can now be
passed to //content/renderer for as long as it's still needed.
Bug: 1102442
Change-Id: Id79fc6117c6b6a091644f41619aa6467550705cd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2445499
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Mario Sanchez Prada <mario@igalia.com>
Cr-Commit-Position: refs/heads/master@{#819436}
Since BrowserPlugin has been removed, references to BrowserPlugin are
now either dead code or misnomers due to also being used in the OOPIF
based guest view implementation. To help reduce confusion, we remove
noticeably dead code from BrowserPlugin related classes in content,
remove BrowserPlugin related delegates or delegate methods no longer
used by content, and move delegate methods still called by code outside
content to the derived guest view classes.
Bug: 533069
Change-Id: I049ba6595fe86a44078051a12d341ee5b99a8c23
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2401031
Commit-Queue: Kevin McNee <mcnee@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Istiaque Ahmed <lazyboy@chromium.org>
Cr-Commit-Position: refs/heads/master@{#810711}
This logic was originally implemented to allow the webrequest API to
block navigations without triggering an error page inside a <webview>
guest (see https://crbug.com/284741). However, the current implementation
allows the renderer to ignore a call to `CommitFailedNavigation()`. To
make it easier to ensure that browser and renderer state remain in sync,
handle this suppression on the browser side instead.
Bug: 284741, 1117282
Change-Id: I63c835953ca3b309c6a0cb8e1f9f889906784db1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2393253
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: James MacLean <wjmaclean@chromium.org>
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Cr-Commit-Position: refs/heads/master@{#806291}
As the first step to convert ViewMsg_UpdateWebPreferences,
we need to move WebPreferences from //content to
//third_party/blink because the IPC message passes WebPreferences
struct.
So, this CL moves WebPreferences to
//third_party/blink/public/common/web_preferences as
a pre-work.
Additionally, this CL wraps all enums and WebPreferences
with web_pref namespace to avoid duplicating the existing
enum types in bliink.
AX-Relnotes: N/A
Bug: 1097943
Change-Id: I35b3dbd45a8bc4bc36a55d7f185d3247fd0b1714
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2397670
Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Matthew Jones <mdjones@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Fabrice de Gans-Riberi <fdegans@chromium.org>
Reviewed-by: Sean Topping <seantopping@chromium.org>
Reviewed-by: Kentaro Hara <haraken@chromium.org>
Reviewed-by: Bo <boliu@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Cr-Commit-Position: refs/heads/master@{#806042}
Convert these two messages to mojo messages on the blink WidgetHost
interface.
Calculation of the composition bounds, current input type are all
moved from RenderWidget into WidgetBase. Some intermediate plumbing
is required since not all input is in blink yet.
BUG=1073560
Change-Id: I67bf118049d3bf186bdd4ff261f25917c097ee17
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2243531
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Tommy Li <tommycli@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#780362}
FrameInputHandler is renamed FrameWidgetInputHandler to indicate that
it actually is an interface on the Widget class that exposes a Frame
interface.
The implementations still remain on the content side for now but
the input is sent to the focused widget. This simplifies setup of the
FrameInputHandler because it used to be associated with the Frame but
really it is associated with the FrameWidget.
The useless content::mojom::Widget interface still exists in some
capacity and will be removed in a followup CL. It just got to big to
do it with this CL.
BUG=1073560
Change-Id: Iec117ebce57f3202cfc8352b5aa13285075840e3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2230912
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Cr-Commit-Position: refs/heads/master@{#776211}
This is a precursor CL needed before adding Mojo traits for
WebDragOperation and WebDragOperationsMask, so that the new dependencies
don't introduce cycles.
Bug: 1039255
Change-Id: I7ab4fb9df4c509bde86570413a6a7174ef878616
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2213561
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Kinuko Yasuda <kinuko@chromium.org>
Commit-Queue: Henrique Ferreiro <hferreiro@igalia.com>
Cr-Commit-Position: refs/heads/master@{#771968}
