chrome.managment API (for extensions) doesn't work properly. #110
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
GnorTech
pushed a commit
that referenced
this pull request
Aug 4, 2018
Fix the tabswitcher overlay when both the EoC and incognito toolbar buttons are shown. Previously, when the incognito toggle button was shown in the toolbar button container the EoC button was incorrectly offset in the tabswitcher animation overlay. The two buttons are now contained in a single FrameLayout and the tabswitcher animation overlay draw logic is adjusted to properly translate to the experimental button. BUG=863819 Change-Id: I4a60f6f15b516f2a7933c3cde4e7a4a23831b0f7 Reviewed-on: https://chromium-review.googlesource.com/1148585 Reviewed-by: Ted Choc <tedchoc@chromium.org> Commit-Queue: Theresa <twellington@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#577599}(cherry picked from commit b4c9587) Reviewed-on: https://chromium-review.googlesource.com/1150544 Reviewed-by: Theresa <twellington@chromium.org> Cr-Commit-Position: refs/branch-heads/3497@{#110} Cr-Branched-From: 271eaf5-refs/heads/master@{#576753}
rogerwang
pushed a commit
that referenced
this pull request
Sep 15, 2018
Adds AudioContext player tracking to MediaEngagementContentsObserver with it's own page level timer. On MediaEngagementSession this CL seperates significant playback into media element playback and audio context playback. Since we may record a playback we need to disable committing on significant playback and just record on destroy or navigate instead. BUG=878460 Change-Id: Ic66152f8cb5b3a6338804c04de7dd0bf5c1cb154 Reviewed-on: https://chromium-review.googlesource.com/1194992 Commit-Queue: Becca Hughes <beccahughes@chromium.org> Reviewed-by: Mounir Lamouri <mlamouri@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#587899}(cherry picked from commit e4555db) Reviewed-on: https://chromium-review.googlesource.com/1211874 Reviewed-by: Becca Hughes <beccahughes@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#110} Cr-Branched-From: 79f7c91-refs/heads/master@{#587811}
rogerwang
pushed a commit
that referenced
this pull request
Oct 31, 2018
TBR=mmoss@chromium.org Change-Id: Ic3cb3e48852467fc5e228c7f252fd5a53d69a889 Reviewed-on: https://chromium-review.googlesource.com/c/1287313 Reviewed-by: chrome-release-bot@chromium.org <chrome-release-bot@chromium.org> Cr-Commit-Position: refs/branch-heads/3578@{#110} Cr-Branched-From: 4226ddf-refs/heads/master@{#599034}
rogerwang
pushed a commit
that referenced
this pull request
Dec 18, 2018
…ails. This relates to http://crrev/c/1340940 , where the class of the bottombar layout was changed in autofill_assistant_sheet.xml, but not in the corresponding cast in BottomBarAnimations.java:setBottomBarHeight(). This merge request was approved here: https://bugs.chromium.org/p/chromium/issues/detail?id=911035 Bug: 806868 Change-Id: Id2bd5bf41862afe7e8425188a2fc048c478726c8 Reviewed-on: https://chromium-review.googlesource.com/c/1356981 Reviewed-by: Mathias Carlen <mcarlen@chromium.org> Commit-Queue: Clemens Arbesser <arbesser@google.com> Cr-Original-Commit-Position: refs/heads/master@{#612702}(cherry picked from commit e5dcd97) Reviewed-on: https://chromium-review.googlesource.com/c/1365596 Reviewed-by: Stephane Zermatten <szermatt@chromium.org> Cr-Commit-Position: refs/branch-heads/3626@{#110} Cr-Branched-From: d897fb1-refs/heads/master@{#612437}
rogerwang
pushed a commit
that referenced
this pull request
Feb 10, 2019
…ere: http://crbug.com/927205 [Autofill Assistant] Fix bug in ShowDetailsAction. Before this patch, users selecting "Go Back" when asked to confirm inconsistent details caused a crash. This was caused by std::move being called twice on the same callback. This patch gets rid of the crash by keeping the callback in the action instance instead of the individual callbacks. Bug: 806868 Change-Id: I6f8520e4f3b97bed40369cc95f19c5d2e763f95f Reviewed-on: https://chromium-review.googlesource.com/c/1442651 Reviewed-by: Mathias Carlen <mcarlen@chromium.org> Commit-Queue: Stephane Zermatten <szermatt@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#626978}(cherry picked from commit c5c8dab) Reviewed-on: https://chromium-review.googlesource.com/c/1449571 Reviewed-by: Stephane Zermatten <szermatt@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#110} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Without shadow dom, the shadow-TextPrompt, the _proxyElement now contains a <style> tag Bug: 934813 Change-Id: I5e3c9f33b94bae244587e549d6869055f08ee833 Reviewed-on: https://chromium-review.googlesource.com/c/1490193 Commit-Queue: Joel Einbinder <einbinder@chromium.org> Reviewed-by: Erik Luo <luoe@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635806}(cherry picked from commit dc97231) Reviewed-on: https://chromium-review.googlesource.com/c/1497414 Reviewed-by: Joel Einbinder <einbinder@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#711} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Bug: 935942 Change-Id: Ie9e5c340b5b036a7fb9588b1e0c6518478f6317f Reviewed-on: https://chromium-review.googlesource.com/c/1492932 Reviewed-by: Dmitry Gozman <dgozman@chromium.org> Commit-Queue: Joel Einbinder <einbinder@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#636235}(cherry picked from commit 751f792) Reviewed-on: https://chromium-review.googlesource.com/c/1497314 Reviewed-by: Joel Einbinder <einbinder@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#712} Cr-Branched-From: e510299-refs/heads/master@{#625896}
WebAuthn requests originating from cryptotoken are executed in the RenderFrame of the cryptotoken background page. Hence, navigation events in the U2F request's sender tab have no influence over the lifetime of the request. This means the corresponding WebAuthn request lives on until it eventually times out; new requests are immediately resolved with a PENDING_REQUEST error in the meantime. As a workaround, have AuthenticatorImpl cancel any pending request, when a new request from the cryptotoken extension arrives. This will make the post-reload u2f request cancel the zombie pre-reload request. However, it will also make subsequent requests (across tabs) cancel any pending requests, whereas before cryptotoken proxying requests would have been queued. Bug: 935480 Change-Id: I6c8986ab010d687efae14927328d3a3eb900ea4a Reviewed-on: https://chromium-review.googlesource.com/c/1490892 Commit-Queue: Martin Kreichgauer <martinkr@google.com> Commit-Queue: Adam Langley <agl@chromium.org> Reviewed-by: Adam Langley <agl@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635872}(cherry picked from commit 80f73e8) Reviewed-on: https://chromium-review.googlesource.com/c/1497492 Reviewed-by: Martin Kreichgauer <martinkr@google.com> Cr-Commit-Position: refs/branch-heads/3683@{#713} Cr-Branched-From: e510299-refs/heads/master@{#625896}
This reverts commit ca8f384. Reason for revert: Breaks event propagation to shelf buttons in login screen when GAIA screen for adding a new user is shown (the dialog is currently a system modal dialog). Original change's description: > System modal dialog should block shelf/status/system tray. > > Bug: 914133 > Test: covered by unit tests. Also tested manually, including OOBE. > Change-Id: I6bbb76092aecbca8c378d050187c958bc8fa9450 > Reviewed-on: https://chromium-review.googlesource.com/c/1396794 > Commit-Queue: Mitsuru Oshima <oshima@chromium.org> > Reviewed-by: Steven Bennetts <stevenjb@chromium.org> > Cr-Commit-Position: refs/heads/master@{#620401} TBR=oshima@chromium.org,stevenjb@chromium.org,jamescook@chromium.org Bug: 914133, 935995 Change-Id: If92888dc4b8714d3764ed257085c44e1dd874289 Reviewed-on: https://chromium-review.googlesource.com/c/1497194 Reviewed-by: Jacob Dufault <jdufault@chromium.org> Commit-Queue: Tony De Luna <tonydeluna@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#636973}(cherry picked from commit a860e1a) Reviewed-on: https://chromium-review.googlesource.com/c/1497359 Cr-Commit-Position: refs/branch-heads/3683@{#714} Cr-Branched-From: e510299-refs/heads/master@{#625896}
…signed exchange. Bug: 935050 Change-Id: Ibca81508ba52743695d170281ff06670f83923e4 Reviewed-on: https://chromium-review.googlesource.com/c/1493338 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Reviewed-by: Kouhei Ueno <kouhei@chromium.org> Commit-Queue: Tsuyoshi Horo <horo@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#636331}(cherry picked from commit 73af162) Reviewed-on: https://chromium-review.googlesource.com/c/1496407 Reviewed-by: Tsuyoshi Horo <horo@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#715} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Bug: 937030 Change-Id: I44721aafb7e778f8887411b7c46e3d786bccd59d Reviewed-on: https://chromium-review.googlesource.com/c/1496315 Reviewed-by: Esmael El-Moslimany <aee@chromium.org> Commit-Queue: Hector Carmona <hcarmona@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#636694}(cherry picked from commit 38abfbf) Reviewed-on: https://chromium-review.googlesource.com/c/1497500 Reviewed-by: Hector Carmona <hcarmona@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#716} Cr-Branched-From: e510299-refs/heads/master@{#625896}
TBR=govind@chromium.org Change-Id: I451455d5f44f39a70db4a1bf7349029df0202174 Reviewed-on: https://chromium-review.googlesource.com/c/1496282 Reviewed-by: chrome-release-bot@chromium.org <chrome-release-bot@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#717} Cr-Branched-From: e510299-refs/heads/master@{#625896}
It has been observed that we are hitting the CHECK(parent_ns_view) in WebContentsNSViewBridge::SetParentNSView. Partially revert r625255, the culprit patch, by moving the functionality of WebContentsNSViewBridge::SetParentNSView in to the caller, NativeViewHostMac::AttachNativeView. This is not a reasonable long-term solution, but is the most reasonable merge candidate. Follow-on patches will move the CHECK up into NativeViewHostMac::AttachNativeView to see exactly why this is happening. TBR=ccameron@chromium.org (cherry picked from commit f129e62) Bug: 933679 Change-Id: I08b19f3123bbe96c49376a41f28a879a855bee62 Reviewed-on: https://chromium-review.googlesource.com/c/1487888 Commit-Queue: ccameron <ccameron@chromium.org> Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635705} Reviewed-on: https://chromium-review.googlesource.com/c/1497859 Reviewed-by: ccameron <ccameron@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#718} Cr-Branched-From: e510299-refs/heads/master@{#625896}
* 302s during CONNECT for subresources now fails with ERR_HTTPS_PROXY_TUNNEL_RESPONSE_REDIRECT. * 302s during CONNECT are rejected for auto-detected proxies * Non auto-detected proxies are still able to redirect CONNECTs for main frames, as we evaluate the compatibility impact for removing it. This CL also records the frequency of redirects during CONNECT in the Net.Proxy.RedirectDuringConnect histogram. (cherry picked from commit 74103c7) Bug: 928551 Change-Id: I99b9148268469251af9f55fea54ac4ccd6bb13a5 Reviewed-on: https://chromium-review.googlesource.com/c/1497754 Reviewed-by: Eric Roman <eroman@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#719} Cr-Branched-From: e510299-refs/heads/master@{#625896}
TBR=abdulsyed@chromiue.org Change-Id: If76475ac3e01ee97abfcff673f238efd69b4c24a Reviewed-on: https://chromium-review.googlesource.com/c/1496285 Reviewed-by: chrome-release-bot@chromium.org <chrome-release-bot@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#720} Cr-Branched-From: e510299-refs/heads/master@{#625896}
TBR=cmasso@chromium.org Change-Id: I88fc48b71abcb921b66de541f55f466f1ca436ca Reviewed-on: https://chromium-review.googlesource.com/c/1498617 Reviewed-by: chrome-release-bot@chromium.org <chrome-release-bot@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#721} Cr-Branched-From: e510299-refs/heads/master@{#625896}
…und and background. Bug: 936355 Change-Id: I5d9e685ca063be7af28cf999adf249766209f911 Reviewed-on: https://chromium-review.googlesource.com/c/1491232 Commit-Queue: Maajid <maajid@chromium.org> Reviewed-by: Shao-Chuan Lee <shaochuan@chromium.org> Reviewed-by: Christopher Thompson <cthomp@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#636710}(cherry picked from commit 713085d) Reviewed-on: https://chromium-review.googlesource.com/c/1498734 Reviewed-by: Maajid <maajid@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#722} Cr-Branched-From: e510299-refs/heads/master@{#625896}
…apiVDA VaapiVideoDecodeAccelerator doesn't propagate profile change in a video stream to driver. Rockchip and Intel driver apparently handles the profile change inside of the drivers, while AMD driver doesn't. This casues video corruption in some sites on AMD device. This is the workaround for the issue. MojoVideoDecoderService calls Initialize() if profile change is detected, but VdaVideoDecoder doesn't support reinitialization as a VideoDecodeAccelerator doesn't. This change enables VdaVideoDecoder to re-initialize by destroying currently using VideoDecodeAccelerator and creating a new one. This reinitialization is triggered only if profile changes for performance and VideoDecodeAccelerator is VaapiVideoDecodeAccelerator for safety. Bug: 929565 Test: no video corruption on some issued sites on grunt and eve Change-Id: Ic6f75809fce6db08965cf0554e7d989d635d3f54 Reviewed-on: https://chromium-review.googlesource.com/c/1482357 Commit-Queue: Hirokazu Honda <hiroh@chromium.org> Reviewed-by: Dan Sanders <sandersd@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#634957}(cherry picked from commit 6579c2b) Reviewed-on: https://chromium-review.googlesource.com/c/1498257 Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#723} Cr-Branched-From: e510299-refs/heads/master@{#625896}
VideoDecoder client, before it calls VD::Initialize, decodes EOS buffer (i.e. VDA::Flush()) first and waits until the EOS buffer is decoed (i.e. VDA::NotifyFlushDone()). Therefore, VdaVideoDecoder doesn't have to call VDA::Flush() in the beginning of reinitialization. This removes the unnnecessary VDA::Flush() call. Bug: 929565 Test: no video corruption on some issued sites on grunt and eve Change-Id: I4e842996896378f0d6f03fc5942833944e3afcaf Reviewed-on: https://chromium-review.googlesource.com/c/1487758 Reviewed-by: Dan Sanders <sandersd@chromium.org> Commit-Queue: Hirokazu Honda <hiroh@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635777}(cherry picked from commit 6e5244c) Reviewed-on: https://chromium-review.googlesource.com/c/1498258 Reviewed-by: Hirokazu Honda <hiroh@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#724} Cr-Branched-From: e510299-refs/heads/master@{#625896}
…ere: http://crbug.com/937233 [Autofill Assistant] Introduces a new command line parameter to set the server url. The new parameter is 'autofill-assistant-url'. This allows us to remove the dependency on finch trials to be able to override the server url from the command line (see related CL cr/235482708). Bug: 937233 Change-Id: I9bfd115483b0304d110e4029833edb64db4e8c64 Reviewed-on: https://chromium-review.googlesource.com/c/1494656 Reviewed-by: Stephane Zermatten <szermatt@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/1498873 Cr-Commit-Position: refs/branch-heads/3683@{#725} Cr-Branched-From: e510299-refs/heads/master@{#625896}
The renderer's surface should not be destroyed while it is still visible, because future CompositorFrames to that surface will be rejected. Bug: 933374 Change-Id: I46c34bad903f052bfd2ee43e6b673a8ef26fca30 Reviewed-on: https://chromium-review.googlesource.com/c/1495368 Commit-Queue: Saman Sami <samans@chromium.org> Reviewed-by: Eric Karl <ericrk@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#636567}(cherry picked from commit b0e9d50) Reviewed-on: https://chromium-review.googlesource.com/c/1497529 Reviewed-by: Saman Sami <samans@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#726} Cr-Branched-From: e510299-refs/heads/master@{#625896}
…ling other content" Revert "Partial Fix to Android Omnibox scrolling revealing other content" This reverts commit 935a93c. Reason for revert: Test revert to bisect regression Original change's description: > Partial Fix to Android Omnibox scrolling revealing other content > > ChromeFullscreenManager::updateViewportSize calculates the changes in control > offsets, and determines when to toggle the resizing of the renderer's view. > > Currently all viewport updates are blocked while a gesture or scrolling is > occurring. > > This change updates the method to also perform the update if we've changed the > resize state. Allowing the renderer to resize to account for the larger region > when scrolling the controls away. > > While this prevents showing older content, it only does so for normal speed > scrolls. A quick flick can lead to such a rapid change in viewport, that we > still have some frames of old content. > > Bug: 916144 > Change-Id: Ibbf8d6daa89691945e011022f9509fea4783cfe2 > Reviewed-on: https://chromium-review.googlesource.com/c/1387945 > Reviewed-by: agrieve <agrieve@chromium.org> > Reviewed-by: Matthew Jones <mdjones@chromium.org> > Commit-Queue: Jonathan Ross <jonross@chromium.org> > Cr-Commit-Position: refs/heads/master@{#623741} TBR=agrieve@chromium.org, ericrk@chromium.org, jonross@chromium.org, mdjones@chromium.org (cherry picked from commit 0ab0a8b) Bug: 916144 Change-Id: I9c7df1d8e7d298db3bda532806a85cedbb22890f Reviewed-on: https://chromium-review.googlesource.com/c/1491139 Reviewed-by: Eric Karl <ericrk@chromium.org> Reviewed-by: Jonathan Ross <jonross@chromium.org> Commit-Queue: Jonathan Ross <jonross@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#636017} Reviewed-on: https://chromium-review.googlesource.com/c/1499594 Cr-Commit-Position: refs/branch-heads/3683@{#727} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Change the message in the recording notification so that it doesn't show a "0%" buffer usage forever. Bug: 932769 Change-Id: I193b656ef264147fa62ec8b788dff9720580d756 Reviewed-on: https://chromium-review.googlesource.com/c/1476991 Reviewed-by: Sami Kyöstilä <skyostil@chromium.org> Commit-Queue: Eric Seckler <eseckler@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#633227}(cherry picked from commit 094af4a) Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1499463 Reviewed-by: Eric Seckler <eseckler@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#728} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Bug: 935963 Test: manual. Change-Id: I7db0bc37d8085ac3f812818542d1a9dd6f8465de Reviewed-on: https://chromium-review.googlesource.com/c/1489533 Auto-Submit: David Tseng <dtseng@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Dominic Mazzoni <dmazzoni@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635682}(cherry picked from commit 172fda3) Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1499721 Reviewed-by: David Tseng <dtseng@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#729} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Bug: 937487 Change-Id: I2d985e28c56d4a7626e3d0c11a8be6d31499a66b Reviewed-on: https://chromium-review.googlesource.com/c/1497631 Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Commit-Queue: Christopher Thompson <cthomp@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#637049}(cherry picked from commit 1b661f8) Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1499724 Reviewed-by: Christopher Thompson <cthomp@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#730} Cr-Branched-From: e510299-refs/heads/master@{#625896}
TBR=eugenebut@chromium.org (cherry picked from commit f26a1aa) Bug: 934379 Change-Id: Idaaffef3e449f3ea7250028f6507c5ebb63d1d12 Reviewed-on: https://chromium-review.googlesource.com/c/1483736 Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org> Commit-Queue: Eugene But <eugenebut@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635237} Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1499839 Reviewed-by: Eugene But <eugenebut@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#731} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Bug: 932148 Change-Id: I24e6b181842913d8da3d02c10e1816636a01454d Reviewed-on: https://chromium-review.googlesource.com/c/1490194 Auto-Submit: Kurt Horimoto <kkhorimoto@chromium.org> Reviewed-by: Eugene But <eugenebut@chromium.org> Commit-Queue: Kurt Horimoto <kkhorimoto@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635749}(cherry picked from commit c421c88) Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1500136 Reviewed-by: Kurt Horimoto <kkhorimoto@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#732} Cr-Branched-From: e510299-refs/heads/master@{#625896}
(Merge to M73.) Authenticators may return WRONG_LENGTH to indicate that a credential is not recognised in addition to WRONG_DATA. Bug: 937438 Change-Id: I3a92a4b98ab6bb2e90c61a4c1a3647c80967f81e Reviewed-on: https://chromium-review.googlesource.com/c/1497292 Reviewed-by: Martin Kreichgauer <martinkr@google.com> Commit-Queue: Martin Kreichgauer <martinkr@google.com> Cr-Original-Commit-Position: refs/heads/master@{#636986}(cherry picked from commit aac3a38) Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1500137 Reviewed-by: Adam Langley <agl@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#733} Cr-Branched-From: e510299-refs/heads/master@{#625896}
During the name fix flow, the cardholder name is empty at times (reason unknown, but mostly because of sync) In such a scenario, we should have the save card button on the dialog disabled by default Bug: 929421 Change-Id: I195422134a263bc201caec2059f4834f7476eb43 Reviewed-on: https://chromium-review.googlesource.com/c/1487144 Reviewed-by: Sebastien Seguin-Gagnon <sebsg@chromium.org> Reviewed-by: Jared Saul <jsaul@google.com> Commit-Queue: Siddharth Shah <siashah@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#635617}(cherry picked from commit 1dc71be) Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1500196 Cr-Commit-Position: refs/branch-heads/3683@{#734} Cr-Branched-From: e510299-refs/heads/master@{#625896}
Bug: 936754 Change-Id: Ia8f042623f31b16cbd88ffdb47a82b05b3bd71e2 Reviewed-on: https://chromium-review.googlesource.com/c/1497124 Commit-Queue: John Abd-El-Malek <jam@chromium.org> Reviewed-by: Devlin <rdevlin.cronin@chromium.org> Reviewed-by: Min Qin <qinmin@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#637068}(cherry picked from commit ab1c9af) Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1500028 Reviewed-by: John Abd-El-Malek <jam@chromium.org> Cr-Commit-Position: refs/branch-heads/3683@{#735} Cr-Branched-From: e510299-refs/heads/master@{#625896}
To avoid contacing Google, let the UA use safebrowsing lists hosted at iridiumbrowser. The Iridium project re-gathers these lists on a regular basis.
This patch makes it possible for distributions to have a global default preferences file in /etc/iridium-browser/preferences that get copied over to ~ when the user starts the program for the first time.
(Position Independent Executable.) This patch originally from openSUSE, chromium-sandbox-pie.patch.
As per http://www.chromium.org/administrators/turning-off-auto-updates , the auto update function is decidedly disabled on Linux, i.e. the following patch is for Windows and MacOS. For Windows, all we need is to build without -DGOOGLE_CHROME_BUILD (cf. chrome/installer/util/google_update_settings.cc), which may already be the case anyway, since we are based off Chromium, not Chrome.
…g.de The list contains mimetype-to-plugin mappins, as well as blacklists for security-impeded old versions of plugins. To avoid contacing Google, let the UA use the plugin list hosted at iridiumbrowser. The Iridium project re-gathers these lists on a regular basis.
The team chose to let EV certificates appear just like normal certificates. The web of trust is considered a failure in itself, so do not give users a false sense of extra security with EV certs. Instead, let them appear just like regular ones.
A trk:193 alert would show whenever the Omnibar is set to use Google as search engine. When it does, it tries to find the most suitable TLD for your request. Well, since we do not use Google as default search engine, this entry can be whitelisted, i.e. have no trk: prefix.
This avoids trk:263 from triggering.
The Chromium codebase has left us with a number of suspect URLs, and we want to know if the browser attempts to contact those sites. This patch introduces a new scheme, "trk:", which, when attempted to being processed, will dump a warning onto the screen as the resource is loaded. All URLs we think are suspect are "blacklisted" by prepending the new scheme to an existing URL: trk:1234:https://clients4.google.com/ trk:https://clients4.google.com/ (unnumbered old variant) trk:0.1234:https://... (stderr only, no UI reporting) Upon seeing a warning, we then know to investigate further, and either (a) whitelist the URL, that is, remove the trk: prefix and not show the warning, and/or (b) disable the particular feature which caused the loading of the URL in the first place, by default. Implementation: We hack up the URLFetcher class which sits in the network stack, and most of the URL that get loaded pass through here. The trk: prefix is stripped and processing continues with the inner URL.
Despite auto-updater being arguably disabled (see previous commit), Chromium would still send background requests. Kill it. (trk:170, trk:171)
Disables the safebrowsing incident reporting where you could upload information about a blocked URL to Google (also added a trk prefix to the URL so we get notified if this happens again in the future).
Disables reporting of the safebrowsing override, i.e. the report sent if a user decides to visit a page that was flagged as "insecure". This prevents trk:148 (phishing) and trk:149 (malware).
Disables sending/setting cookies for Safebrowsing requests. This prevents the long-living tracking cookie from being set. References: https://github.com/iridium-browser/iridium-browser/issues/37
Documentation is scarce, and sprinkled with misleading acronyms. NTP is not NTP, for example. FWIW: // A PromoResourceService fetches data from a web resource server to // be used to dynamically change the appearance of the New Tab Page. // For example, it has been used to fetch "tips" to be displayed on // the NTP, or to display promotional messages to certain groups of // Chrome users. Whatever it is that it downloads, deactivate the one that leads to Google. References: https://github.com/iridium-browser/iridium-browser/issues/33
Avoid loading the search page everytime, just show a blank one instead. References: https://github.com/iridium-browser/iridium-browser/issues/32
Because replacing kChromeUIWelcomeURL with about:blank leads the browser to load some broken URL instead.
The attached patch makes sure that component extensions are always shown in "chrome://extensions". Currently these are - Bookmark Manager - Chromium PDF Viewer - CryptoTokenExtension References: https://github.com/iridium-browser/iridium-browser/issues/28
The W3C Battery Status API[1] has quite a laughable statement: "The information disclosed has minimal impact on privacy or fingerprinting, and therefore is exposed without permission grants". Along comes a paper "The leaking battery, A privacy analysis of the HTML5 Battery Status API." Clean up after the W3C and disable the battery status updater which could be used to identity users[2]. [1] http://www.w3.org/TR/battery-status/ [2] https://eprint.iacr.org/2015/616.pdf References: https://github.com/iridium-browser/iridium-browser/issues/40
This patch is for debugging purposes and is meant for discovering whether despite our patching efforts metrics_reporting is still enabled somehow, and if so, say so on stderr. Result: As of October 2014, metrics_reporting seems successfully disabled, as no message is emitted.
Prefix URLs to Google services with trk: so that whenever something tries to load them, the developer will be informed via printf and dialog about this infraction. If you see such dialog, we know that (a) either the URL needs to be whitelisted, or (b) the feature that triggered it needs to be disabled by default.
Smooth scrolling (while using mousewheel or arrow keys) is a really dumb idea. Text naturally appears as a blur while it moves, and the animation takes that-many milliseconds to finish, so it's a time waster too. Only the fallback setting, which is used on Linux, is changed; on Windows/MacOS, smooth scrolling remains controlled by a system setting.
Reduced version number: We do not use @build@ or @patch@, in particular not in the User-Agent string. As for the user agent, continue providing Chrome/* for possible compatibility checks by the browser and/or websites, since we really are still Chromium. Note to self: Update "Chromium/*" in UA string when updating chrome/version.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After trying to figure out why this extension managing extension works on Chromium, but not in Iridium, I found the chrome.manament API to be the issue.
The litmus test I've been using is
chrome.management.getAll((extensions) => { console.log(extensions); });. If you run this in the Inspect Popup Console of the aforementioned extension in Chromium, you will get an array of all the extensions you have installed logged in the console. Example. In Iridium, you just get an empty array.