- 06 Jun, 2016 40 commits
-
-
zmo authored
BUG= TEST=gpu bots TBR=kbr@chromium.org NOTRY=true CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2044593002 Cr-Commit-Position: refs/heads/master@{#398103}
-
mboc authored
BUG=617055 https://codereview.chromium.org/1819753003/ accidentally removed UNDERLINE style support on Linux. This CL fixes the issue. Review-Url: https://codereview.chromium.org/2031223003 Cr-Commit-Position: refs/heads/master@{#398102}
-
Reilly Grant authored
VibrationTest.CancelVibrationFromMainFrameWhenMainFrameIsReloaded BUG=617727 TBR=oshima@chromium.org Review URL: https://codereview.chromium.org/2047503002 . Cr-Commit-Position: refs/heads/master@{#398101}
-
jaydasika authored
Right now, we do a layer tree walk for iteration over all layers on impl-side (LayerListIterator). Once we start pushing layer list instead of layer tree during commit/activation, we will use layer_list instead(layers will be added to layer_list in stacking order during commit/activation). A lot of tests build layer tree on the impl-side and don't go through commit/activation. So, we need to explicitly build the layer_list for these tests. BUG=617366 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review-Url: https://codereview.chromium.org/2032303004 Cr-Commit-Position: refs/heads/master@{#398100}
-
fdoray authored
MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon are deprecated. This CL makes the following replacements to remove some uses of these methods: "MessageLoop(ForUI|ForIO)::current()->PostTask" -> "ThreadTaskRunnerHandle::Get()->PostTask" "MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" -> "ThreadTaskRunnerHandle::Get()->PostDelayedTask" "MessageLoop(ForUI|ForIO)::current()->DeleteSoon" -> "ThreadTaskRunnerHandle::Get()->DeleteSoon" "MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" -> "ThreadTaskRunnerHandle::Get()->ReleaseSoon" In files where these replacements are made, it adds these includes: #include "base/location.h" #include "base/single_thread_task_runner.h" #include "base/threading/thread_task_runner_handle.h" And removes this include if it is no longer required: #include "base/message_loop/message_loop.h" Why ThreadTaskRunnerHandle::Get() instead of MessageLoop::current()->task_runner()? - The two are equivalent on threads that run a MessageLoop. - MessageLoop::current() doesn't work in base/task_scheduler because the scheduler's thread don't run MessageLoops. This CL will therefore facilitate the migration of browser threads to base/task_scheduler. Steps to generate this patch: 1. Run message_loop_cleanup.py (see code on the bug). 2. Run tools/sort-headers.py on modified files. 3. Run git cl format. BUG=616447 R=piman@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:linux_optional_gpu_tests_rel;tryserver.chromium.mac:mac_optional_gpu_tests_rel;tryserver.chromium.win:win_optional_gpu_tests_rel Review-Url: https://codereview.chromium.org/2035943002 Cr-Commit-Position: refs/heads/master@{#398099}
-
pauljensen authored
Rename it to purgeActiveNetworkList which better reflects its actual function. It only purges the list of inactive networks, and does not add to the list. R=xunjieli Review-Url: https://codereview.chromium.org/1967373003 Cr-Commit-Position: refs/heads/master@{#398098}
-
gogerald authored
This CL is a strength of https://codereview.chromium.org/1952853005/. BUG=607695 Review-Url: https://codereview.chromium.org/2032043002 Cr-Commit-Position: refs/heads/master@{#398097}
-
erikchen authored
Revert of Re-enable WebGL Image Chromium. (patchset #3 id:40001 of https://codereview.chromium.org/2025973002/ ) Reason for revert: I'm observing a behavior difference between the Image CHROMIUM and non-Image CHROMIUM path. Turning off Image CHROMIUM while I investigate. https://bugs.chromium.org/p/chromium/issues/detail?id=617249#c5 Original issue's description: > Re-enable WebGL Image Chromium. > > This CL makes DrawingBuffer use the newly added DescheduleUntilFinishedCHROMIUM, > and turns on IOSurface backed WebGL by default. > > BUG=581777 > > Committed: https://crrev.com/801f15833c140f120a2f5baed88645cb0619ab86 > Cr-Commit-Position: refs/heads/master@{#397603} TBR=kbr@chromium.org,avi@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=581777 Review-Url: https://codereview.chromium.org/2041053002 Cr-Commit-Position: refs/heads/master@{#398096}
-
wangxianzhu authored
It's temporarily plumbed on PaintInvalidationState to let it work for spv2. Will gradually switch to new code, using the paint property data collected by PaintPropertyTreeBuilder. Enable SlimmingPaintInvalidation by default when spv2 is enabled. BUG=510908 Review-Url: https://codereview.chromium.org/2033183002 Cr-Commit-Position: refs/heads/master@{#398095}
-
brettw authored
This should be a behavior no-op. The nontrivial "is enabled" and "execute" commands are now split into helper functions using a consistent style. This helps make the multi-hundred-line-long switch statements more manageable. Review-Url: https://codereview.chromium.org/2035033003 Cr-Commit-Position: refs/heads/master@{#398094}
-
timav authored
It seems some implementations thow an undocumented exception from MediaDrm.closeSession(). This CL catches and ignores all of them. BUG=611865 Review-Url: https://codereview.chromium.org/2038193003 Cr-Commit-Position: refs/heads/master@{#398093}
-
bcf authored
Aggressive inlining causes -Wstrict-overflow to be triggered. BUG=616957 BUG=internal b/29059135 Review-Url: https://codereview.chromium.org/2036613002 Cr-Commit-Position: refs/heads/master@{#398092}
-
ben authored
R=sky@chromium.org Review-Url: https://codereview.chromium.org/2038143003 Cr-Commit-Position: refs/heads/master@{#398091}
-
robhogan authored
Fix off-by-one error in https://crrev.com/385513 BUG=617553 Review-Url: https://codereview.chromium.org/2040963002 Cr-Commit-Position: refs/heads/master@{#398090}
-
dschuyler authored
This CL fixes an issue with the scroll to section not finding its host element. A unit test has also been added to detect the issue. BUG=616186 CQ_INCLUDE_TRYBOTS=tryserver.chromium.linux:closure_compilation Review-Url: https://codereview.chromium.org/2022893003 Cr-Commit-Position: refs/heads/master@{#398089}
-
fdoray authored
MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon are deprecated. This CL makes the following replacements to remove some uses of these methods: "MessageLoop(ForUI|ForIO)::current()->PostTask" -> "ThreadTaskRunnerHandle::Get()->PostTask" "MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" -> "ThreadTaskRunnerHandle::Get()->PostDelayedTask" "MessageLoop(ForUI|ForIO)::current()->DeleteSoon" -> "ThreadTaskRunnerHandle::Get()->DeleteSoon" "MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" -> "ThreadTaskRunnerHandle::Get()->ReleaseSoon" In files where these replacements are made, it adds these includes: #include "base/location.h" #include "base/single_thread_task_runner.h" #include "base/threading/thread_task_runner_handle.h" And removes this include if it is no longer required: #include "base/message_loop/message_loop.h" Why ThreadTaskRunnerHandle::Get() instead of MessageLoop::current()->task_runner()? - The two are equivalent on threads that run a MessageLoop. - MessageLoop::current() doesn't work in base/task_scheduler because the scheduler's thread don't run MessageLoops. This CL will therefore facilitate the migration of browser threads to base/task_scheduler. Steps to generate this patch: 1. Run message_loop_cleanup.py (see code on the bug). 2. Run tools/sort-headers.py on modified files. 3. Run git cl format. BUG=616447 R=reillyg@chromium.org Review-Url: https://codereview.chromium.org/2036863002 Cr-Commit-Position: refs/heads/master@{#398088}
-
brucedawson authored
Many executables are missing embedded manifest files when built with gn. This causes OS compatibility information to be omitted which can lead to strange behavior. This adds manifests to two executables. TBR=reed@google.com BUG=602505 Review-Url: https://codereview.chromium.org/2021113003 Cr-Commit-Position: refs/heads/master@{#398087}
-
pfeldman authored
TBR=dgozman Review-Url: https://codereview.chromium.org/2038363003 Cr-Commit-Position: refs/heads/master@{#398086}
-
yuweih authored
In some situations the same JniClient will be used for multiple connections where ConnectToHost()->DisconnectFromHost()->ConnectToHost() will be called. In ConnectToHost() we DCHECK !secret_fetcher_ but don't release it in DisconnectFromHost(), which fails the DCHECK. This CL solves this problem by resetting |secret_fetcher_| in DisconnectFromHost(). However, we still need to investigate why JniClient is being used for multiple connections. BUG=617471 Review-Url: https://codereview.chromium.org/2046663002 Cr-Commit-Position: refs/heads/master@{#398085}
-
primiano authored
Revert of In official builds, let CHECK(false) crash instead of calling BreakDebugger. (patchset #2 id:20001 of https://codereview.chromium.org/1982123002/ ) Reason for revert: Unfortunately crrev.com/1982123002 causes loss of crash reports on Android arm64 (and supposedly also CrOS). This is because __builtin_trap() raises a SIGILL on x86 and arm but SIGTRAP on arm64. Breakpad does not handle SIGTRAP (yet). Temporarily reverting this CL until SIGTRAP support for breakpad lands. BUG=599867,614865 Original issue's description: > In official builds, let CHECK(false) crash instead of calling BreakDebugger. > > This should save some binary size and make things a bit faster, without ill > effects. > > See bug comment 15, and brettw's and my comments on > "[blink-dev] Update of wtf/Assertions.h, and ASSERT macros deprecation" > > BUG=599867 > > Committed: https://crrev.com/481a8ec8b24df24795c63fd4ec26f3670d516db8 > Cr-Commit-Position: refs/heads/master@{#394035} TBR=danakj@chromium.org,thakis@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=599867 Review-Url: https://codereview.chromium.org/2046593002 Cr-Commit-Position: refs/heads/master@{#398084}
-
timav authored
Since AudioCodecBridge::ConfigureAndStart creates AudioTrack instance with config parameters, we need to initialize the output parameters with the same values before we get OnOutputFormatChanged(). Without this step the some changes between config and actual parameters will be undetected, for instance before this change (1) config_num_channels = 2, output_num_channels = 2 old output value was 0, unnecessary AudioTrack recreation (2) config_num_channels = 1, output_num_channels = 2 old output value was 2, no change detected here but AudioTrack was created with num_channels = 1 BUG=none Review-Url: https://codereview.chromium.org/2042563002 Cr-Commit-Position: refs/heads/master@{#398083}
-
fdoray authored
MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon are deprecated. This CL makes the following replacements to remove some uses of these methods: "MessageLoop(ForUI|ForIO)::current()->PostTask" -> "ThreadTaskRunnerHandle::Get()->PostTask" "MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" -> "ThreadTaskRunnerHandle::Get()->PostDelayedTask" "MessageLoop(ForUI|ForIO)::current()->DeleteSoon" -> "ThreadTaskRunnerHandle::Get()->DeleteSoon" "MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" -> "ThreadTaskRunnerHandle::Get()->ReleaseSoon" In files where these replacements are made, it adds these includes: #include "base/location.h" #include "base/single_thread_task_runner.h" #include "base/threading/thread_task_runner_handle.h" And removes this include if it is no longer required: #include "base/message_loop/message_loop.h" Why ThreadTaskRunnerHandle::Get() instead of MessageLoop::current()->task_runner()? - The two are equivalent on threads that run a MessageLoop. - MessageLoop::current() doesn't work in base/task_scheduler because the scheduler's thread don't run MessageLoops. This CL will therefore facilitate the migration of browser threads to base/task_scheduler. Steps to generate this patch: 1. Run message_loop_cleanup.py (see code on the bug). 2. Run tools/sort-headers.py on modified files. 3. Run git cl format. BUG=616447 R=maxbogue@chromium.org Review-Url: https://codereview.chromium.org/2033933002 Cr-Commit-Position: refs/heads/master@{#398082}
-
robhogan authored
This was an error in the refactoring at https://codereview.chromium.org/1323313004. BUG=615056 Review-Url: https://codereview.chromium.org/2042623002 Cr-Commit-Position: refs/heads/master@{#398081}
-
rune authored
There seems to be nothing called InspectorFrontend. Removed unused forward declarations for it and changed comments to say "frontend" instead. R=pfeldman@chromium.org,dgozman@chromium.org Review-Url: https://codereview.chromium.org/2046433002 Cr-Commit-Position: refs/heads/master@{#398080}
-
drott authored
FontDataCache's key data type was a full FontPlatformData object, not a pointer to one The value type of that cache is a SimpleFontData object, which in itself stores a FontPlatformData object type. If we want to manage memory related to font blobs (OpenType tables, web font file buffers) we need to come to a situation where the lifecycle of FontPlatformData objects is absolutely clear. Previously, adding to the FontDataCache meant one copy of FontPlatformData for the cache key, and one for the value as an owned member of SimpleFontData. In this situation, it is much harder to keep track of where we keep FontPlatformData objects. FontPlatformData objects keep a RefPtr<HarfBuzzFace>, which in turn keeps hb_font objects, which keep references to OpenType tables copied from Skia. If we cannot destroy FontPlatformData objects after use, we cannot free the corresponding copied OpenType tables - so over the lifetime of the renderer we're leaking OpenType table data for stale FontPlatformData objects. This is a first step towards fixing this situation and gaining better control over the lifecylce of FontPlatformData objects. BUG=617568 R=eae,tzik,bashi Review-Url: https://codereview.chromium.org/2031363002 Cr-Commit-Position: refs/heads/master@{#398079}
-
weiliangc authored
Separate clip rect and visible rect calculation so visible rect logic would be easier to follow. R=ajuma BUG=594675 CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review-Url: https://codereview.chromium.org/2008283003 Cr-Commit-Position: refs/heads/master@{#398078}
-
dewittj authored
Adds a test to make sure sequential navs are handled correctly, and also add histogram checks to all tab helper tests. BUG=589526 Review-Url: https://codereview.chromium.org/2040573002 Cr-Commit-Position: refs/heads/master@{#398077}
-
rmistry authored
Context: This bot has not been running for about 2 months now. When it was running it did not generate any useful alerts. These files were originally added in https://codereview.chromium.org/1410353007/ # Failing with missing LGTM from OWNER for chrome/ct_top1k.isolate even though M-A LGTM'ed. TBR=maruel BUG=skia:4503 Review-Url: https://codereview.chromium.org/2039973002 Cr-Commit-Position: refs/heads/master@{#398076}
-
xjz authored
MediaStreamDispatcher::OnDeviceStopped() may delete the same element twice from |label_stream_map_| and causes the crash. BUG=616884 Review-Url: https://codereview.chromium.org/2035993002 Cr-Commit-Position: refs/heads/master@{#398075}
-
hariank authored
Account now switches when focus changes, not just updated wallpaper. BUG=614926 Review-Url: https://codereview.chromium.org/2035753003 Cr-Commit-Position: refs/heads/master@{#398074}
-
sebsg authored
The previous CL was built around a test case I had made myself (there was no real life example). I found one and realized the type should be "text" and not "input". Related CL: https://codereview.chromium.org/2025063002/ BUG=616174 TEST=AutofillFieldTest Review-Url: https://codereview.chromium.org/2041863003 Cr-Commit-Position: refs/heads/master@{#398073}
-
rdevlin.cronin authored
The extension TabHelper can have an associated extension if the WebContents holds a hosted app. Watch for that extension being unloaded and reset the reference to the extension if it is so that we don't UAF it. BUG=616057 BUG=616113 Review-Url: https://codereview.chromium.org/2037873002 Cr-Commit-Position: refs/heads/master@{#398072}
-
chfremer authored
The name content::VideoFrameProvider was easy to cause confusion with cc:VideoFrameProvider. Furthermore, the methods provided in the content::VideoFrameProvider are not specific to Video, which makes the name somewhat unsuitable. List of changes: * Moved the typedef content::VideoFrameProvider::RepaintCB out to a new file and renamed it to VideoFrameCallback. * Renamed interface VideoFrameProvider to PausableStream * Renamed method Play() to Resume() BUG=526835 Review-Url: https://codereview.chromium.org/2005053006 Cr-Commit-Position: refs/heads/master@{#398071}
-
tommycli authored
This is just a mechanical rename and reformat. The rename is good because: 1) WebUI::CallJavascriptFunctionUnsafe is indeed unsafe and the caller is responsible for knowing when it is safe to call. 2) WebUIMessageHandler::CallJavascriptFunction is the new preferred way. 3) The change makes the above two points clear to coders not to use WebUI directly unless they know what they are doing. In the future, WebUI::CallJavascriptFunctionUnsafe may become a private member with a few friend classes. See design doc for more details: https://docs.google.com/a/chromium.org/document/d/1z1diKvwgMmn4YFzlW1kss0yHmo8yy68TN_FUhUzRz7Q/edit?usp=sharing BUG=602523 Review-Url: https://codereview.chromium.org/1995113002 Cr-Commit-Position: refs/heads/master@{#398070}
-
sadrul authored
BitmapUploader is needed only for chrome when it uses software rendering. So instead of always creating a BitmapUploader (which creates an extra surface for the window) for every widget, create it only when needed. BUG=none Review-Url: https://codereview.chromium.org/2040453002 Cr-Commit-Position: refs/heads/master@{#398069}
-
rob.buis authored
Reject calcs with both lengths and percentages in radial-gradient, while for ellipse both length and percentage are allowed, they are not allowed at the same time [1]. [1] https://drafts.csswg.org/css-images-3/#radial-gradients Review-Url: https://codereview.chromium.org/1935173002 Cr-Commit-Position: refs/heads/master@{#398068}
-
bokan authored
In https://codereview.chromium.org/2025393003/ I moved the visualViewport object from document onto window but forgot to move the event to fire on the window instead. BUG=595826 Review-Url: https://codereview.chromium.org/2034313002 Cr-Commit-Position: refs/heads/master@{#398067}
-
sky authored
BUG=none TEST=covered by tests R=jamescook@chromium.org Review-Url: https://codereview.chromium.org/2033843003 Cr-Commit-Position: refs/heads/master@{#398066}
-
hans authored
Revert of Suppress -Wnonportable-include-path on clang tot bots (patchset #2 id:20001 of https://codereview.chromium.org/2040533003/ ) Reason for revert: The Clang warning was removed again in r271761. Original issue's description: > Suppress -Wnonportable-include-path on clang tot bots > > BUG=617318 > R=hans@chromium.org > > Committed: https://chromium.googlesource.com/chromium/src/+/2bc751024e4ddf3f50594abdbf3c54b77df84562 TBR=thakis@chromium.org # Not skipping CQ checks because original CL landed more than 1 days ago. BUG=617318 Review-Url: https://codereview.chromium.org/2043813002 Cr-Commit-Position: refs/heads/master@{#398065}
-
fdoray authored
MessageLoop::PostTask/PostDelayedTask/DeleteSoon/ReleaseSoon are deprecated. This CL makes the following replacements to remove some uses of these methods: "MessageLoop(ForUI|ForIO)::current()->PostTask" -> "ThreadTaskRunnerHandle::Get()->PostTask" "MessageLoop(ForUI|ForIO)::current()->PostDelayedTask" -> "ThreadTaskRunnerHandle::Get()->PostDelayedTask" "MessageLoop(ForUI|ForIO)::current()->DeleteSoon" -> "ThreadTaskRunnerHandle::Get()->DeleteSoon" "MessageLoop(ForUI|ForIO)::current()->ReleaseSoon" -> "ThreadTaskRunnerHandle::Get()->ReleaseSoon" In files where these replacements are made, it adds these includes: #include "base/location.h" #include "base/single_thread_task_runner.h" #include "base/threading/thread_task_runner_handle.h" And removes this include if it is no longer required: #include "base/message_loop/message_loop.h" Why ThreadTaskRunnerHandle::Get() instead of MessageLoop::current()->task_runner()? - The two are equivalent on threads that run a MessageLoop. - MessageLoop::current() doesn't work in base/task_scheduler because the scheduler's thread don't run MessageLoops. This CL will therefore facilitate the migration of browser threads to base/task_scheduler. Steps to generate this patch: 1. Run message_loop_cleanup.py (see code on the bug). 2. Run tools/sort-headers.py on modified files. 3. Run git cl format. BUG=616447 R=danakj@chromium.org CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel Review-Url: https://codereview.chromium.org/2034913002 Cr-Commit-Position: refs/heads/master@{#398064}
-