When https://crbug.com/404294118 was reverted, a comment was left in
the code noting the conditions for which a re-land would be possible.
After the revert, a second regression was reported, so update the
code comment with a pointer on the issue, so that it can be avoided
when the re-land happens.
Bug: 389067059
Bug: 404294118
Change-Id: I895e6cae81bd36115858efbd32e5648c710d6289
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6373059
Reviewed-by: Jayson Adams <shrike@chromium.org>
Commit-Queue: Jayson Adams <shrike@chromium.org>
Auto-Submit: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1434861}
This is to fix the issue that Apple intelligence's writing tools grabs
the focus from browser after the user click replace button in writing
tools bubble which causes the replaced text can not be inserted into
browser IME since the content's NSView loses focus. Please note that
this is a workaround fix and should be removed after the issue is
finally fixed by Apple which is tracked via FB16872510.
Bug: 385170286
Change-Id: Ied94e2c3eba320cfeeb1eea68f6a5527e6ccd6ba
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6320619
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Leon Han <shulianghan@microsoft.com>
Commit-Queue: Fei Chen <feich@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1434585}
https://crrev.com/c/6173642 switched to new API for doing popup menus,
but it also did some associated cleanup. While the new API was buggy
(see https://crbug.com/401443090) and therefore had to be reverted, the
cleanup aspects are still a good idea, so re-land them.
Specifically:
- Switching WebMenuRunner to have explicit testing callbacks rather
than requiring other code to swizzle NSView with the knowledge of
the WebMenuRunner internals.
- Removal of the "useWithPopUpButtonCell" parameter on
MenuControllerCocoa, which was not actually used for
PopUpButtonCells! (The WebMenuRunner builds its own menus.)
- Removal of the default -init on MenuControllerCocoa due to having no
callers; now MenuControllerCocoa always eagerly builds the menu,
simplifying things.
- Light code modernization.
Bug: 389067059
Include-Ci-Only-Tests: chromium.mac:mac14-tests|browser_tests
Change-Id: If62fd54001c9ad2c50e6bd96a97c894b00a7bc61
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6351721
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Keren Zhu <kerenzhu@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1433321}
There is a bug in macOS where the usage of NSMenu.minimumWidth
causes menu items to be prematurely truncated. Given that
this is on Stable, do a clean revert.
Disabling the style warning because this is a revert. The
cleanup code will be re-landed later.
This reverts commit 1786625b69.
DISABLE_OBJECTIVE_C_STYLE
Bug: 389067059
Bug: 401443090
Change-Id: I1e06296f7647010a3ca36395b2a42953ec448203
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6347626
Commit-Queue: Keren Zhu <kerenzhu@chromium.org>
Reviewed-by: Keren Zhu <kerenzhu@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Auto-Submit: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1431666}
This cl forces the web contents to ignore any incoming text
correction that appies to an older version of the web contents's
text, avoiding a crash.
Bug: 372217922
Change-Id: Iaf502a04af58fba395cadc12652ddd6ccaed520c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6299632
Commit-Queue: Jayson Adams <shrike@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1427904}
The RenderWidgetHostViewCocoa and BridgedContentView implementations of
-validRequestorForSendType:returnType: serve the same purpose but are
written differently. Rewrite both to make them structured the same way
and to be the most clear we can make them.
Rename "return" to "accept" to clarify the direction of the flow of
data.
This is not intended to change the functionality of the method.
Bug: 385170286
Change-Id: I9f29e107f237ce77628bfde907f302d36c17c8ab
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6254138
Auto-Submit: Avi Drissman <avi@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1418874}
There are two places that Services are handled (Views and Web) and
both have to work around the same compatibility bugs. Centralize the
handling for the bugs.
This also generalizes the compatibility workaround. Will this help
with Writing Tools? Unknown, but generalizing the workaround can't
hurt.
Bug: 385170286
Change-Id: I8e575daa0e8f4d64edfb5a9ad1890d23c54f401c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6245493
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Auto-Submit: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1418420}
Control-clicking at the end of a line of text in a text field selects
the last word (standard Mac behavior). If you select Emoji & Symbols
from the menu, and choose an emoji, the emoji will replace the
selected text. Effectively, there's no way to insert an emoji at an
insertion point when invoking the emoji panel via the contextual
menus. This cl clears the selection created by the contextual menu. It
restores the insertion point to its previous location in most cases.
One note: after the code in this cl restores the insertion point, the
insertion point is visible in the text but doesn't blink. This seemed
to suggest something wrong with the solution, but it's easy to repro
the same behavior as a user by control-clicking a selection and
pressing an arrow key.
Bug: 40572113
Change-Id: I7cb1f2367afd48fb225b0512ab6f2dfaf7bb2607
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6190724
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Jayson Adams <shrike@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1412382}
Using an NSPopUpButtonCell to do popups is borderline SPI, plus
NSPopUpButtonCell plays some super weird games with having a first
item that is magic/used for tool tips. Switch to supported API, and
do cleanup.
This was committed as r1406461 and reverted because the positioning
wasn't as good as it could be. This change includes two differences:
1. The change to headless mode was moved out to its own CL,
https://chromium-review.googlesource.com/c/chromium/src/+/6187262
2. The positioning of the menu is improved.
Fixed: 389067059
Bug: 389084419
Change-Id: Id40b2f20c93c9bf05a40c96af457fcac7e6c1324
Low-Coverage-Reason: HARD_TO_TEST macOS API integration
Include-Ci-Only-Tests: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6173642
Reviewed-by: Keren Zhu <kerenzhu@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1409709}
This reverts commit 80592c0315.
Reason for revert: crbug.com/390072746
Original change's description:
> Do popups using modern API
>
> Using an NSPopUpButtonCell to do popups is borderline SPI, plus
> NSPopUpButtonCell plays some super weird games with having a first
> item that is magic/used for tool tips. Switch to supported API, and
> do cleanup.
>
> Fixed: 389067059
> Bug: 389084419
> Low-Coverage-Reason: HARD_TO_TEST macOS API integration
> Include-Ci-Only-Tests: true
> Change-Id: Ic6643e7ba9408a7e5844837cabd82a9849b7d700
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6165888
> Auto-Submit: Avi Drissman <avi@chromium.org>
> Commit-Queue: Avi Drissman <avi@chromium.org>
> Reviewed-by: Leonard Grey <lgrey@chromium.org>
> Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
> Reviewed-by: Keren Zhu <kerenzhu@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1406461}
Bug: 389084419
Change-Id: I744031a11cfb65f68b7661dc3abe4e687701c27d
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6175281
Owners-Override: Darwin Yang <darwinyang@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Auto-Submit: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1406749}
Using an NSPopUpButtonCell to do popups is borderline SPI, plus
NSPopUpButtonCell plays some super weird games with having a first
item that is magic/used for tool tips. Switch to supported API, and
do cleanup.
Fixed: 389067059
Bug: 389084419
Low-Coverage-Reason: HARD_TO_TEST macOS API integration
Include-Ci-Only-Tests: true
Change-Id: Ic6643e7ba9408a7e5844837cabd82a9849b7d700
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6165888
Auto-Submit: Avi Drissman <avi@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Keren Zhu <kerenzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1406461}
Ensure that `performOcclusionStateUpdates` and `setWebContentsVisibility` check if content::GetContentClient() is nullptr before proceeding. Add necessary safeguards to prevent the crash when content::GetContentClient() is nullptr.
Bug: 385901565
Change-Id: I336982157f115517343db38223e4aabdcb6afa89
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6110550
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Leon Han <shulianghan@microsoft.com>
Commit-Queue: Lichen Liu <lichenliu@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1403344}
Learn more about the circumstances that cause an exception
to be thrown in -doubleClickAtIndex:.
Bug: 372217922
Change-Id: I43807c8779ae415e04ca446fe06ae44146429eb9
Low-Coverage-Reason: EXPERIMENTAL_CODE
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6065021
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Jayson Adams <shrike@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1391098}
We still saw crashes at a base::checked_cast<> in a gfx::Range
constructor. This CL adds a base::saturated_cast<> to a parameter
of the constructor to avoid the crashes.
Bug: 40226470, 40060200, 40945573
Change-Id: Icc72cfbc5f9dc0efbbdfe50dd6a795cd463e2db5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6040040
Auto-Submit: Kent Tamura <tkent@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1386844}
NOTREACHED() and NOTREACHED_IN_MIGRATION() are both CHECK-fatal now.
The former is [[noreturn]] so this CL also performs dead-code removal
after the NOTREACHED().
This CL does not attempt to do additional rewrites of any surrounding
code, like:
if (!foo) {
NOTREACHED();
}
to CHECK(foo);
Those transforms take a non-trivial amount of time (and there are
thousands of instances). Cleanup can be left as an exercise for the
reader.
This does clean up kCrashOnDanglingBrowserContext as both paths of the
kill switch are currently fatal. This has been rolled out for a long
time.
Bug: 40580068, 40062641
Change-Id: Ib88e710d003e2e48df3fc502ca54d2341d157a0e
Cq-Include-Trybots: luci.chromium.try:linux-dcheck-off-rel
Low-Coverage-Reason: OTHER Should-be-unreachable code
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5974816
Reviewed-by: Łukasz Anforowicz <lukasza@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Peter Boström <pbos@chromium.org>
Reviewed-by: Sam McNally <sammc@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1376522}
https://crrev.com/c/5949433 added screen orientation handling to
headless shell, however, the related tests fail on Macs due to
the check for the enclosing NSWindow to exist preventing screen
properties change to be passed to the upper layers.
This CL removes the excessively aggressive check allowing screen
properties change to be handled normally when running headless
in which case enclosing NSWindow never exists.
Bug: 375425824
Change-Id: I44392e2536a6a7122b5574bac068ebef2b210fc2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5967373
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Commit-Queue: Peter Kvitek <kvitekp@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1375988}
NS_VALID_UNTIL_END_OF_SCOPE is a macro for the objc_precise_lifetime
attribute. It was used more than the attribute, so standardize on
using it.
Bug: none
Change-Id: Ic7e52c30db87ab655dc31f429c56ecf10a314741
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5891478
Commit-Queue: Avi Drissman <avi@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Reviewed-by: Mark Cogan <marq@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1360512}
This change moves all BrowserAccessibility* classes except for android from content/browser/accessibility to ui/accessibility/platform/
OneShotAccessibilityTreeSearch is also moved in this change, as it both depends on BrowserAccessibility, and is used by it.
Why is android not moved?
Android's implementation of BrowserAccessibility* is coupled
with the concept of web contents, and since Android does not use views, working to uncouple Android will arguably add more complexity than having the types split. See https://chromium-review.googlesource.com/c/chromium/src/+/5350788 for an example of what this would look like.
For unchanged code where we moved a file into ui and should now drop ui:: in the ui namespace, I'll be putting together a follow up change that does this for all of ui/accessibility. ui/accessibility/ already has heavy usage of ui:: within the ui namespace and leaving these changes out for now helps highlight any functional differences exist in these moved files.
Why do this at all?
Moving BrowserAccessibility and BrowserAccessibilityManager to the UI
layer will allow us to share the functionality of these classes with
Views as well, allowing us to have a consistent accessibility
implementation, while also enabling Views to utilize our caching
mechanisms, allowing us to stop recomputing everything on each
accessibility API call to views.
See Design Document for additional details: https://docs.google.com/document/d/1Ku7HOyDsiZem1yaV6ccZ-tz3lO2XR2NEcm8HjR6d-VY/edit#heading=h.dmka4gmkfbri
Bug: 40672441
Change-Id: I36b3c7913f059f77ddfaaa2b046976fb65062c8a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5520052
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Reviewed-by: Benjamin Beaudry <benjamin.beaudry@microsoft.com>
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Aaron Leventhal <aleventhal@chromium.org>
Commit-Queue: Jacques Newman <janewman@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1346888}
The NSPasteboardWriting protocol requires the method
-pasteboardPropertyListForType: to return a property list compatible
type, thus the method is declared to have a return type of `id`, being
effectively untyped.
The caller does not verify that the call actually returns an object
of a valid type for this purpose. It just stores it at the time. If
there is any issue with the type of the value returned, it will show
up later.
In https://crrev.com/c/5738733, as part of macOS 11 modernization, the
drag code was modernized so that an ivar, which used to hold an
NSString, was modernized to hold a UTType. While most usage of that
ivar was correctly updated, the fact that the return type of
-pasteboardPropertyListForType: was `id` obscured the error that was
introduced: that a UTType was returned from that method (a non-
property list compatible type) rather than the required string (which
is the desired property list compatible type).
Therefore, fix the bug by returning the identifier rather than the
UTType object.
Fixed: 356666758
Change-Id: I088363b0250cb88bbd9ba5aa1cfbddf76ee7c748
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5752287
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Commit-Queue: Leonard Grey <lgrey@chromium.org>
Auto-Submit: Avi Drissman <avi@chromium.org>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1335732}
This CL propagates the initiator origin via
`content::DragDownloadFile::DragDownloadFileUI::InitiateDownload`
into `download::DownloadUrlParameters::set_initiator`.
Note that the initiator origin comes from trustworthy, browser-side data:
- `RenderFrameHostImpl::StartDragging` passes `GetLastCommittedOrigin()`
into `RenderViewHostDelegateView::StartDragging`
- `WebContentsViewAura::StartDragging` stores the origin into into
`ui::OSExchangeDataProviderFactory` using a call to
`ui::OSExchangeDataProviderFactory::MarkRendererTaintedFromOrigin`.
On Windows this CL takes the origin from
`OSExchangeDataProviderFactory` and passes it directly into
`DragDownloadFile`'s constructor.
- `WebContentsViewMac::StartDragging` ends up storing the origin in
`WebDragSource` from `web_drag_source_mac.mm`. On Mac this CL takes
this origin and also passes it (indirectly, via mojo) into
`DragDownloadFile`'s constructor.
@lukasza has manually tested this CL on Windows using the repro steps
from https://crbug.com/40060358 (@dcheng has kindly tried the repro
steps on Mac). Note that `DragDownloadFile` is used on Windows and Mac,
but not on Linux (i.e. the repro wouldn't have worked on Linux).
Fixed: 40060358
Change-Id: I24b180473e140cbb8a56640444f2f4a306aa42fc
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5692867
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1327773}
LatencyTracker was used to calculate UMAs/UKMs based on the start of
swap time. These have all been replaced by variants that calculate to
presentation time.
There were a few remaining UKMs left. The total latency now have
variants for presentation time. The others were never correctly
aggregated, and the breakdown coverage we have is sufficient.
This removes LatencyTracker along with some params in LatencyInfo that
were only ever relevant to these metrics.
Bug: 334977830
Change-Id: Ic09c1f7caa38edb57364ef6e689d80f83a693442
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5663414
Reviewed-by: Robert Kaplow <rkaplow@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Reviewed-by: Hidehiko Abe <hidehiko@chromium.org>
Reviewed-by: ccameron chromium <ccameron@chromium.org>
Commit-Queue: Jonathan Ross <jonross@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1326804}
This changes the <select> popups on Mac so that they ellipsize
excessively large options that don't fit in the popup. Prior to this
change the behavior was to attempt to wrap such options; however, the
wrapped text was not displayed. In the case of an <optgroup> (which
causes indentation) the old behavior could mean that an option that was
a single large unbreakable unit could end up showing nothing at all.
Fixed: 348675991
Change-Id: I41f46048291f228c390f105b851f23055a0833d0
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5665600
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Commit-Queue: David Baron <dbaron@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1321282}
Code that tickles the ObjC runtime into calling
+[WebContentsViewCocoa initialize] would instantiate an occlusion
checker, even in processes that can't use it. This cl ensures the
occlusion checker only gets created in the main browser process.
Test: out/default/content_browsertests \
--gtest_filter=*WindowOcclusionBrowserTestMacWithOcclusionDetectionFeature*
Bug: 349984532, 40808805
Change-Id: Ie907d30931916c94874343bb8d796a4fb206cd38
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5668239
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Jayson Adams <shrike@chromium.org>
Code-Coverage: findit-for-me@appspot.gserviceaccount.com <findit-for-me@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1321147}
Async Clipboard API has a standardized web custom format[1] and
having another web custom type for the DataTransfer API that is
Chromium-only creates confusion, so rename the custom MIME types used
for the DataTransfer API from `kUTTypeChromiumWebCustomData` to
`kUTTypeChromiumDataTransferCustomData` and `kMimeTypeWebCustomData`
to `kMimeTypeDataTransferCustomData`.
[1] https://w3c.github.io/clipboard-apis/#optional-data-types-x
Bug: 333952122
Change-Id: I993ffe52cb2780d3878e48b85f6f8a4374265629
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5627852
Reviewed-by: Christine Hollingsworth <christinesm@chromium.org>
Reviewed-by: Sanket Joshi <sajos@microsoft.com>
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Anupam Snigdha <snianu@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1316533}
Suppress unsafe buffer usage on a file-by-file basis. Out of
approximately 5850 .cc and .h files only roughly 160 files fail
compilation with the unsafe buffers warning.
Suppress only, by inserting boilerplate into affected files. Do not
re-write any code to work around the issues. Properly fixing each file
will be done in follow-up CLs.
//content/ is not removed from unsafe_bufers_paths.txt file and will be
also done as a follow-up, so it makes potential reverts simpler.
Bug: 342213636
Change-Id: I4a936e63dea95a78951f7bfae6d5487708ae3c0b
AX-Relnotes: n/a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5608913
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Nasko Oskov <nasko@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1312393}
This CL sets up a new component `input` which can be depended upon by
browser and viz. The requirement is part of InputVizard project[1] where
touch input handling is being moved to Viz on Android. Earlier we had
been refactoring input related bits from browser classes and placing
them in //content/common/input but since Viz cannot depend on content
the input code is being moved into a component of it's own[2].
Apart from setting up the component we are moving web_keyboard_event
related code in the component. In the future CLs we will be moving more
input related code here.
P.S. `$ git cl format` has re-ordered some of the headers, they weren't
intentionally re-ordered.
[1] https://docs.google.com/document/d/1mcydbkgFCO_TT9NuFE962L8PLJWT2XOfXUAPO88VuKE
[2] Google internal discussion thread g/chrome-input/wWPmYmVkFWY/IqCZNJr-AAAJ
Bug: b/340182114
Change-Id: Ic531f0a77a514ab31bf125cc69806dbf860caf44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5541976
Reviewed-by: Colin Blundell <blundell@chromium.org>
Reviewed-by: Giovanni Ortuno Urquidi <ortuno@chromium.org>
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Reviewed-by: Stephen Nusko <nuskos@chromium.org>
Reviewed-by: Mitsuru Oshima <oshima@chromium.org>
Commit-Queue: Kartar Singh <kartarsingh@google.com>
Cr-Commit-Position: refs/heads/main@{#1307299}
Since RenderWidgetHostNSViewBridge might get deleted while displaying a
popup menu, it is not safe to use base::AutoReset to reset the
showing_popup_menu_ member. So use absl::Cleanup with a weak pointer
instead.
Bug: 338162110
Change-Id: Ic907b2e6541d095eebee2c13a778b2d46afa54ed
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5564186
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Commit-Queue: Marijn Kruisselbrink <mek@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1305164}
This was generated by replacing " NOTREACHED()" with
" NOTREACHED_IN_MIGRATION()" and running git cl format.
This prepares for making NOTREACHED() [[noreturn]] alongside
NotReachedIsFatal migration of existing inventory.
Bug: 40580068
Change-Id: I3b48b89911ac5e9ffcb211622992f917f8f9e8d9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5539619
Auto-Submit: Peter Boström <pbos@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Owners-Override: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Commit-Queue: Peter Boström <pbos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1301096}
Top Chrome WebUIs are expected to behave like views UIs, where currently
a big difference lies in handling mouse events in inactive windows.
While views UIs allow hover effects and clicks to pass through when the
window is inactive, Top Chrome WebUIs did not. This patch allows Top
Chrome WebUIs to accept mouse events when the host window is inactive.
Specifically, mouse move and click event are handled with subtle
differences:
* mouse move: accepts the event if the application is active (the
content window could be inactive).
* mouse click: always accepts the event.
Note that, the mouse move behavior aligns with views UI, but this is not
the behavior of other native macOS apps (e.g Notes, Safari), where move
events are also always handled in the non-content area.
A new method, acceptsMouseEventsOption, is added to
RenderWidgetHostViewMacDelegate. It returns an AcceptMouseEventsOption
enum of three possible options:
* kAcceptMouseEventsInActiveWindow
* kAcceptMouseEventsInActiveApp
* kAcceptMouseEventsAlways
For render widgets that host Top Chrome WebUIs, the browser now returns
kAcceptMouseEventsInActiveApp, allowing interaction with inactive
windows within an active app.
This change applies to both trusted and untrusted Top Chrome WebUIs.
Bug: 40791625, 338127521
Change-Id: Ie9d31afa202e7ee5215f3be5746c3c84aa7577da
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5516009
Reviewed-by: Avi Drissman <avi@chromium.org>
Commit-Queue: Keren Zhu <kerenzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1297056}
According to crash/cd43669b61c2483b, `_markedRange.location +
NSMaxRange(newSelRange)` can be huge.
We avoid a CHECK failure in gfx::Range constructor by
base::saturated_cast<>().
Bug: 40226470, 40060200, 40945573
Change-Id: I5ed7d715ebf4f700933e39edcd6a2f26c8f7506b
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5514947
Commit-Queue: Avi Drissman <avi@chromium.org>
Auto-Submit: Kent Tamura <tkent@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1296059}
Supports reshow on first input: https://crrev.com/c/5445712
(only user mouse input should trigger bubble reshow logic)
Skip ExclusiveAccessManager::OnUserInput on mouse enter/exit/synth.
(e.g. generated from window state changes with no user input)
Ping ExclusiveAccessManager::OnUserInput on mouse click/scroll/etc.
Plumb ui::Event from WebContents to Browser::ContentsMouseEvent()
Add automated test for reshowing on move or click after snooze.
Bug: 40941384
Test: Automated; fullscreen bubble shows on click w/o move after 15m.
Change-Id: I2da8e7e9540bf83a2ec9f4e59e9cb9596196f846
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469260
Commit-Queue: Mustafa Emre Acer <meacer@chromium.org>
Reviewed-by: Takumi Fujimoto <takumif@chromium.org>
Auto-Submit: Mike Wasserman <msw@chromium.org>
Commit-Queue: Mike Wasserman <msw@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: John Abd-El-Malek <jam@chromium.org>
Commit-Queue: Takumi Fujimoto <takumif@chromium.org>
Reviewed-by: Mustafa Emre Acer <meacer@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1292769}
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}
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: Iabdfea2fd5393d6bbc54390ca0c995eb2c55bbaa
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5469882
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@{#1290673}
The previous attempt to fix this bug utilized `-recalculateKeyViewLoop`
which was only effective for macOS 14.
This CL removes the `-recalculateKeyViewLoop` workaround and instead
prevents the infinite loop by ensuring the browser window's first
responder is not a descendant of the closing web contents view.
Bug: 324812653
Change-Id: Ia275d8921bbc8bbf2e1704ea0e29bfa1175c73d6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5462479
Commit-Queue: Tom Burgin <bur@google.com>
Reviewed-by: Leonard Grey <lgrey@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1288963}
Before this CL, `RenderWidgetHostViewMac::is_visible_` and
RenderWidgetHostViewCocoa's NSView hidden state was desynced until the
former is explicitly updated.
`RenderWidgetHostViewMac::is_visible_` is initialized as false.
However, as mek@ found in https://crrev.com/c/4808654 , the NSView is
initially set to visible.
This CL fixes the issue by setting RenderWidgetHostViewCocoa
as hidden as soon as after it is created, to be consistent with the initial status of `RenderWidgetHostViewMac::is_visible_ = false`
Please refer to go/mystery2 for more detailed explanation.
Test: Tested manually. Since the issue is flaky and synthetic inputs are routed correctly, this is hard to test via code.
Bug: 326509142
Change-Id: I60a237470a1bc7197192b9c21e4bd0a46f739170
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5404373
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Auto-Submit: Kouhei Ueno <kouhei@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1280970}
ATs making accessibilityRole requests probably don't care about full
web a11y support, but currently that's what we turn on. For the
Sonoma experiment, enable native API support only.
Bug: 41481640
Test: out/debug/browser_tests --gtest_filter=ChromeBrowserAppMac*
out/debug/content_browsertests --gtest_filter=RenderWidgetHostViewMacTest.RespondToAccessibilityRoleRequestsOnWebContent
Include-Ci-Only-Tests: true
Change-Id: I29a2da11261a4bca3b399993d6d664c811f28edd
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5302421
Commit-Queue: Jayson Adams <shrike@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: David Tseng <dtseng@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1277122}
Bug: 323771594
Implements accessibility hit testing for RemoteCocoa so that Speak Content under the pointer can read the accessible objects under the user's pointer.
This comes from a commit:https://chromium-review.googlesource.com/c/chromium/src/+/3861171 in 2022/9/9 and was reverted on 2023/2/8. The reason why it was reverted is that it causes some macOS tools hangs and OOMs.
Now to resolve A11y related issues(such as hover text or Speak Content under the pointer), I want to re-land it with a feature flag in accessibility_features.h named kAccessibilityRemoteUIApp.
Change-Id: I1924a9e84852f7df2c8ba1259b87e9096ab9a93f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5267921
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Ken Buchanan <kenrb@chromium.org>
Commit-Queue: yan libang <libangyan@microsoft.com>
Cr-Commit-Position: refs/heads/main@{#1263760}
Some Assistive Technology(e.g.Text To Speech) doesn't work on PWA Mac.
There are two reasons:
1. Currently we always incorrectly return nil when ATs access the
current focused element of app shim process.
2. Browser doesn't turn on the accessibility tree, because those ATs
only notify app shim process, not the browser process.
To fix it, we did two things.
1. Use BridgeContentViews's `accessibilityFocusedUIElement` as
focused element, which is `NSAccessibilityRemoteUIElement` in app shim
process. OS will find automatically the deepest element in browser
process by `NSAccessibilityRemoteUIElement`.
2. Notify browser process to turn on/off a11y tree when app shim
process has observed user enabling or disabling AT.
Bug: 1515487, 1150173
Change-Id: I6ab6caa0d44756b706d71146c3179c2d7b9756a5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5224041
Reviewed-by: Jayson Adams <shrike@chromium.org>
Commit-Queue: Xiaofei Han <xiaofeihan@microsoft.com>
Reviewed-by: Marijn Kruisselbrink <mek@chromium.org>
Reviewed-by: Alex Gough <ajgo@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1262075}