This CL exempts WebView prerender API from SpeculativeLoading WebView
setting.
The setting was introduced for Speculation Rules API on WebView. The API
can be triggered by both embedder apps and web apps hosted on WebView.
In the latter case, an embedder app may not expect prerendering is
triggered, and it may break assumption on navigation lifecycle
management. To avoid the situation, embedders should be able to
explicitly control prerendering with the setting.
On the other hand, WebView prerender API can be triggered only by
embedder apps. Calling the API means that an embedder app understands
implication on navigation lifecycle by prerendering, so WebView doesn't
need to gate the feature unlike Speculation Rules API.
Bug: 41490450
Change-Id: I3d7855a916918a2378acfb92722dcab3cd878ee8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6090650
Reviewed-by: Taiyo Mizuhashi <taiyo@chromium.org>
Reviewed-by: Andrey Kosyakov <caseq@chromium.org>
Reviewed-by: Erik Chen <erikchen@chromium.org>
Reviewed-by: Richard (Torne) Coles <torne@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Hiroki Nakagawa <nhiroki@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1396564}
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}
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: Ibc66b8c440e4bcdef414e77fef4d9874d2ea9951
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5493800
Auto-Submit: Alison Gale <agale@chromium.org>
Commit-Queue: Alison Gale <agale@chromium.org>
Reviewed-by: Peter Boström <pbos@chromium.org>
Owners-Override: Alison Gale <agale@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1293330}
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: Iebe070b9ed793ecdfc43c3a3570f1808b7ddd221
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5470014
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@{#1290677}
With BlinkSchedulerPrioritizeNavigationIPCs enabled,
FindRequestManagerTest.FindNewMatches sometimes flakes on tsan/msan
builds. It also flakes occasionally without that flags, but it happens
more often with the flag enabled. FindRequestManagerTest.Basic also
occasionally flakes with the flag enabled, but less frequently.
Looking at traces, in the FindNewMatches passing case, rendering
happens before the first find-in-page IPC. In the failing case, it
happens after. This affects whether or not SendActiveMatch is sent to
the browser, which depends on TextFinder::should_locate_active_rect_
(it's true if we rendered, false if not). The ordering change is more
likely to happen with the experiment enabled since navigation IPCs
might run before CC initialization.
Given the apprarent implicit dependency on rendering, this CL changes
the find-in-page browser tests to wait for a rAF after loading the
page, which fixes the issue locally on a tsan build.
Bug: 330147459
Change-Id: I72c113aef357bbaaf33ca6a9218a68dbfd8a063f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5379084
Commit-Queue: Scott Haseley <shaseley@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1274628}
See bug for a little more detail, but the next push in this area
will probably differ in some key ways that make the maintenance
of this code no longer the best path forward.
There are still some things left after this that can be cleaned
up afterward; this mainly hacks off the vast majority and then
fixes the things needed for the build to work.
AutofillKeyboardAccessoryIntegrationTest claims to be newly flaky,
but the test logic wasn't modified -- the test was simply made no
longer parameterized.
AX-Relnotes: n/a
Bug: 1498140
Validate-Test-Flakiness: skip
Change-Id: If0559e8db7bcbe4fdde0f4321945e962d152984c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5017280
Reviewed-by: Kevin McNee <mcnee@chromium.org>
Commit-Queue: Jeremy Roman <jbroman@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1227518}
With RenderDocument, cross-document navigations will use new
RenderFrameHosts (and RenderViewHosts, RenderWidgetHosts, etc for
main frame navigations). This CL updates some tests in
content_browsertests that didn't expect those changes.
Bug: 936696
Change-Id: Ia43799aaae9f50b7ff9c3221982b622d76698d14
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4349554
Reviewed-by: James Maclean <wjmaclean@chromium.org>
Commit-Queue: Rakina Zata Amni <rakina@chromium.org>
Auto-Submit: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1120489}
When an iframe is loaded after starting a find session,find is
being performed because of options.force even if it's not visible
Remove force override for frame visibilty check and add corresponding
test case
The Original Author has added the override citing HasVisibleContent()
can give inaccurate results but hasn't mentioned the cases anywhere.
The best course of action would be to assume correctness and let the bug
surface and then log a bug for HasVisibleContent().
https://codereview.chromium.org/2236403004/patch/60001/70009
Bug: 1422874
Change-Id: Ic2a4b00ec15859fb9fbde26c8c0b8f8946062beb
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4328807
Reviewed-by: Mahesh Machavolu <mahesh.ma@samsung.com>
Reviewed-by: Bo Liu <boliu@chromium.org>
Commit-Queue: Mahesh Machavolu <mahesh.ma@samsung.com>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1119193}
Due to historical reason, the feature flag for BackForwardCache, i.e.
`kBackForwardCache`, has grown into a complex feature that supports
multiple parameters. To enable the feature in a test and make it stable,
one is required to set up extra parameters, and also required to disable
another feature `kBackForwardCacheMemoryControls`. The whole setup is so
complicated that some tests made wrong usage of them.
This CL is the 1st step to reduce its complexity, by hiding the setup behind team-owned utility functions. In the future, the team may decide to refactor the parameters, and this change help limiting the affected files.
The changes include:
- Rename test utility functions to make them easier to understand.
- Replace most references to `kBackForwardCache` or `kBackForwardCacheMemoryControls` in tests with the above functions
Bug: 1301867
Change-Id: I117196bf639c8e88adc0d813b5f225040516fd0c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4280121
Reviewed-by: Ken Okada <kenoss@chromium.org>
Reviewed-by: Matthias Körber <koerber@google.com>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Yaron Friedman <yfriedman@chromium.org>
Commit-Queue: Ming-Ying Chung <mych@chromium.org>
Reviewed-by: Christoph Schwering <schwering@google.com>
Cr-Commit-Position: refs/heads/main@{#1110890}
Some times tests need to replace the ContentBrowserClient. This
is often done by subclassing ContentBrowserClient and replacing
ContentBrowserClient during test execution. This is problematic
as certain things (such as RegisterBrowserInterfaceBindersForFrame)
are provided by ShellContentBrowserClient, and if not present
result in bad behavior (killing the renderer), which leads to flake.
To fix this problem this patch does the following:
. Moves ContentBrowserTestShellContentBrowserClient to its own
header and renames it to
ContentBrowserTestContentBrowserClient.
. makes SetBrowserClientForTesting() CHECK in content_browsertests.
. changes all browsertests to use
ContentBrowserTestContentBrowserClient.
. Changes ShellContentBrowserClient so that it sets the browser
client when called the second time (effectively what
SetBrowserClientForTesting() does).
Bug: 1406282
Change-Id: Ieaa7cfa09a53e9618b963d6cc4b931226d2c799e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4222392
Commit-Queue: Scott Violet <sky@chromium.org>
Reviewed-by: John Abd-El-Malek <jam@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1102490}
- Remove the logic that uses legacy TTL param from `content/browser/renderer_host/back_forward_cache_impl.cc`
- Move the dedicated TTL feature flag `kBackForwardCacheTimeToLiveControl` to `content/public/common/content_features.h` so that it can replace the usage of legacy param `kBackForwardCache:TimeToLiveInBackForwardCacheInSeconds`
Details:
1. In the previous launch crrv/c/3924019, BackForwardCache's default TTL
has been updated to 600 seconds. The launch also uses a new dedicated
feature flag `kBackForwardCacheTimeToLiveControl` to overwrite the
default from server-side for the older clients.
2. However, in the gigantic flag `kBackForwardCache`, there is a param
called `TimeToLiveInBackForwardCacheInSeconds` which can also
overwrite the default flag. Due to historical reason, the server-side
Finch config still set this flag to 180 seconds.
3. This CL replaces all the references to the legacy param
`kBackForwardCache:TimeToLiveInBackForwardCacheInSeconds` to the new flag `kBackForwardCacheTimeToLiveControl`.
Bug: 1305878
Change-Id: Ia6f5f2c84b1a7f219c31ef681b9ca0a918674ea9
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4177505
Reviewed-by: Danil Somsikov <dsv@chromium.org>
Reviewed-by: Charlie Harrison <csharrison@chromium.org>
Reviewed-by: Reilly Grant <reillyg@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Ryan Sturm <ryansturm@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Yoshisato Yanagisawa <yyanagisawa@chromium.org>
Commit-Queue: Ming-Ying Chung <mych@chromium.org>
Reviewed-by: Martin Šrámek <msramek@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1097212}
This CL replaces the GetPrimaryMainFrame() comparison check in favor
of a more concise method IsInPrimaryMainFrame() in
find_request_manager_browsertest.cc.
Bug: 1268893
Change-Id: Ia30908add31e3fcccb2f203dcaab284cd08d4fd7
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4028639
Commit-Queue: Antia Puentes <apuentes@igalia.com>
Reviewed-by: Bo Liu <boliu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1071741}
This is a reland of commit 143885f9e5https://crrev.com/1045406 reverted this CL as a speculative fix for the
flakiness in https://crbug.com/1362116. The test remains flaky after
the revert, so reland this CL.
Original change's description:
> Fix PDF viewer jumping immediately after the user presses 'ctrl+f'
>
> This behavior is disruptive and inconsistent with the search behavior
> of non-PDF sites. After this commit, pressing 'ctrl+f' will not start
> a search until the user presses additional keys (add characters /
> press enter).
>
> This bug is a side effect of fixing another bug "Chrome PDF Search is
> not executed in background" (crbug.com/764635). The fix reverts the
> changes done by the previous bug fix (pdfium_engine.cc) and provides an
> alternative solution (find_request_manager.cc) which requires to update
> some tests (pdf_find_request_manager_browsertest.cc,
> find_request_manager_browsertest.cc, findtext_unittest.cc).
>
> Lastly this is my first bug so I added my name to AUTHORS.
>
> Bug: 1290824
> Change-Id: I8e152087fb2ac019124e477b4d04d73d7b8f2f21
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3455153
> Commit-Queue: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Joey Arhar <jarhar@chromium.org>
> Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1043764}
Bug: 1290824
Change-Id: I1413c4db077a4cfd5c8e8dafe0a4ff31cd238ec3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3892090
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: K. Moon <kmoon@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1060267}
This reverts commit 143885f9e5.
Reason for revert: Speculative revert for flaky test.
See https://crbug.com/1362116 for details.
Original change's description:
> Fix PDF viewer jumping immediately after the user presses 'ctrl+f'
>
> This behavior is disruptive and inconsistent with the search behavior
> of non-PDF sites. After this commit, pressing 'ctrl+f' will not start
> a search until the user presses additional keys (add characters /
> press enter).
>
> This bug is a side effect of fixing another bug "Chrome PDF Search is
> not executed in background" (crbug.com/764635). The fix reverts the
> changes done by the previous bug fix (pdfium_engine.cc) and provides an
> alternative solution (find_request_manager.cc) which requires to update
> some tests (pdf_find_request_manager_browsertest.cc,
> find_request_manager_browsertest.cc, findtext_unittest.cc).
>
> Lastly this is my first bug so I added my name to AUTHORS.
>
> Bug: 1290824
> Change-Id: I8e152087fb2ac019124e477b4d04d73d7b8f2f21
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3455153
> Commit-Queue: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Lei Zhang <thestig@chromium.org>
> Reviewed-by: Joey Arhar <jarhar@chromium.org>
> Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1043764}
Bug: 1290824, 1362116
Change-Id: I43366129df4a9e44b5413852a029c3a121f8590e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3888066
Owners-Override: Tommy Nyquist <nyquist@chromium.org>
Commit-Queue: Tommy Nyquist <nyquist@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1045406}
This behavior is disruptive and inconsistent with the search behavior
of non-PDF sites. After this commit, pressing 'ctrl+f' will not start
a search until the user presses additional keys (add characters /
press enter).
This bug is a side effect of fixing another bug "Chrome PDF Search is
not executed in background" (crbug.com/764635). The fix reverts the
changes done by the previous bug fix (pdfium_engine.cc) and provides an
alternative solution (find_request_manager.cc) which requires to update
some tests (pdf_find_request_manager_browsertest.cc,
find_request_manager_browsertest.cc, findtext_unittest.cc).
Lastly this is my first bug so I added my name to AUTHORS.
Bug: 1290824
Change-Id: I8e152087fb2ac019124e477b4d04d73d7b8f2f21
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3455153
Commit-Queue: Lei Zhang <thestig@chromium.org>
Reviewed-by: Lei Zhang <thestig@chromium.org>
Reviewed-by: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Pavel Feldman <pfeldman@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1043764}
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 annotates the one firing during content_browsertests.
Multiple follow-up will complete the list, up until being able to
enable dangling pointer detection on a bot.
Stats:
- 175 DanglingUntriaged in code
- 69 DanglingUntriaged in tests
Bug=1291138
Change-Id: I00771bd46403f90297aa5b972fdd1ddc23b18e07
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3687960
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Bartek Nowierski <bartekn@chromium.org>
Owners-Override: Bartek Nowierski <bartekn@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1013525}
This fixes a regression caused by http://crrev.com/956680 where clearing
the find-in-page text box causes a find-in-page to occur with the last
text which was in the box. For example, typing "a" into the text field
and then pressing backspace quickly before the find-in-page request
occurs will make the page get searched for "a" and highlight results
after the find-in-page text field is empty.
This happens because FindRequestManager::Find is not called when the
search is cleared, but FindRequestManager::StopFinding is called
instead, and StopFinding wasn't accounting for the pre-existing delayed
find-in-page query.
This patch fixes it by clearing the delayed find-in-page query when
StopFinding is called.
Fixed: 1286068
Change-Id: I1b9b9e8f58d9a48b24f0ec49e42c1ce8f9b8938c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3544186
Commit-Queue: Joey Arhar <jarhar@chromium.org>
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Reviewed-by: Vladimir Levin <vmpstr@chromium.org>
Cr-Commit-Position: refs/heads/main@{#986254}
This is a reland of 2b80df4d74
The original CL called a private method in the test via friend class.
But, it could cause undefined symbol build error due to the visibility.
To fix it, we need to use CONTENT_EXPORT keyword for the private method
in order to export the symbol of the method to the test class.
Original change's description:
> MPArch: Fenced frame does not clear the find request queue in FindRequestManager::RemoveFrame
>
> FindRequestManager::RemoveFrame method has cleared its own find request
> queue when a given render frame host is a mainframe. This CL makes
> the method only clear the queue on a pimary main frame. Besides
> this CL adds a test case to verify it.
>
> Bug: 1264776
> Change-Id: Iddaaa1eec0d0d332efc54b1a06c9b5e8d936fff2
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255123
> Reviewed-by: Dominic Farolino <dom@chromium.org>
> Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
> Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
> Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
> Cr-Commit-Position: refs/heads/main@{#942951}
Bug: 1264776
Change-Id: I2725610adcd679b45de3a885680124cd214852c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3288660
Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Cr-Commit-Position: refs/heads/main@{#943437}
FindRequestManager::RemoveFrame method has cleared its own find request
queue when a given render frame host is a mainframe. This CL makes
the method only clear the queue on a pimary main frame. Besides
this CL adds a test case to verify it.
Bug: 1264776
Change-Id: Iddaaa1eec0d0d332efc54b1a06c9b5e8d936fff2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3255123
Reviewed-by: Dominic Farolino <dom@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Gyuyoung Kim <gyuyoung@igalia.com>
Cr-Commit-Position: refs/heads/main@{#942951}
Note that the old method is already returning the PrimaryFrameTree so
this patch is just about making that explicit.
Keeping the old method around for a while will also prevent this massive
patch from being reverted if an optional try-bot later fails.
Bug: 1251094
Change-Id: Iea020e175212c92bccf15dc0af1c3ca7e084bbbe
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3259727
Reviewed-by: Alexander Timin <altimin@chromium.org>
Commit-Queue: Carlos Caballero <carlscab@google.com>
Cr-Commit-Position: refs/heads/main@{#938281}
Note that the old method is already returning the PrimaryFrameTree so
this patch is just about making that explicit.
Trivial change that renames all test files leaving the production code
for a later patch. That code will need a closer look to make sure that
call sites are really expecting the primary frame tree (note they are
already getting the primary frame tree, so this is just an extra check
for peace of mind).
Keeping the old method around for a while will also prevent this massive
patch from being reverted if an optional try-bot later fails.
Bug: 1251094
Change-Id: Ibc86aedf203013e41e61ede94e6af929f80ee477
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3231330
Reviewed-by: Alexander Timin <altimin@chromium.org>
Reviewed-by: Sreeja Kamishetty <sreejakshetty@chromium.org>
Commit-Queue: Carlos Caballero <carlscab@google.com>
Cr-Commit-Position: refs/heads/main@{#935359}
This CL observes RenderFrameHostStateChanged instead of
RenderFrameHostChanged and adds the IsActive check so that
we would only run find-in-page on active pages, and also this
adds some checks and tests to ensure that this is true.
Bug: 1245613
Change-Id: I84b5d9dd057a343dea2e8377ac345533ce892e88
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3135523
Commit-Queue: Miyoung Shin <myid.shin@igalia.com>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Reviewed-by: Alexander Timin <altimin@chromium.org>
Cr-Commit-Position: refs/heads/main@{#933813}
For the PDF Viewer, find-in-page should only return results from the
PDF content, and not from the PDF Viewer's UI. In the PPAPI-based PDF
Viewer, the renderer process that hosts the UI has a
blink::WebPluginContainer, and deferring find-in-page operations to that
WebPluginContainer really defers to the PDF plugin. In the PPAPI-free
PDF Viewer, that same process just hosts the PDF renderer and has no
plugin to defer to. The PDF renderer has a blink::WebPluginContainer
instead. With no plugin to defer to, the renderer running the PDF UI
performs find-in-page on its own contents.
To fix this, avoid creating a content::FindInPageClient for the RFH with
the PDF UI. For content::FindRequestManager to make this decision
without direct knowledge of the PDF Viewer, add a generic
ContentBrowserClient::IsFindInPageDisabledForOrigin() interface and
override it in //chrome.
Along the way, add some getters to FindRequestManagerTest to retrieve
commonly used nodes in the FrameTree, and use those in both new test
cases and to simplify existing test cases.
Bug: 1199999
Change-Id: I85dddd90bd4a6a57ba84e3ba8f7c09bdd99bd17e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3229023
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Reviewed-by: Rakina Zata Amni <rakina@chromium.org>
Commit-Queue: Lei Zhang <thestig@chromium.org>
Cr-Commit-Position: refs/heads/main@{#932616}
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}
Match rects in subframe should be recomputed when the size of parent
frame is changed since Find-in-page coordinates are represented as
normalized fractions of the main frame document
Bug:1147796
Change-Id: Iee446b54060b9977f0ed6db8b49c6bf63d1938c1
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2531797
Commit-Queue: HuiWang <wanghui210@huawei.com>
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/heads/master@{#844346}
This CL replaces most calls to NavigateFrameToURL(...) with
EXPECT_TRUE(NavigateToURLFromRenderer(...)). Note that not all such
calls have been replaced (e.g. this CL skips the ones where the
naive/mechanical replacement would have caused test failures).
For motivation (i.e. why NavigateFrameToURL is slightly undesirable)
please see the linked bug.
Bug: 1148049
Change-Id: I5b341c3e7cc2e0774d905705b2ca891dc0be862f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2532855
Auto-Submit: Łukasz Anforowicz <lukasza@chromium.org>
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Łukasz Anforowicz <lukasza@chromium.org>
Cr-Commit-Position: refs/heads/master@{#826989}
The ActiveMatch may be null when make a FindRequest with options that kWrapAround is
false, while the active_rect in |FindRequestManager| will not update when it is
empty then we will show a incorrect tickmark(active_rect of last FindRequest)
on Android. so We should reset the active_rect in |FindRequestManager| when there
is a new FindRequest.
Bug: 1141374
Change-Id: Ieac210a2b72f4f92649e68e1b2e2969fd707dbf2
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2491726
Reviewed-by: Nasko Oskov <nasko@chromium.org>
Reviewed-by: Ted Choc <tedchoc@chromium.org>
Reviewed-by: Filip Gorski <fgorski@chromium.org>
Commit-Queue: Filip Gorski <fgorski@chromium.org>
Cr-Commit-Position: refs/heads/master@{#825424}
