forked from benmccann/chromium
-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Sidebar visible at detached DevTools window #5
Comments
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
…id:80001 of https://codereview.chromium.org/1078123002/) Reason for revert: Suspected as cause of flaky failures for WebViewInteractiveTest.PopupPositioningBasic WebViewInteractiveTest.PopupPositioningMoved. For details, see https://code.google.com/p/chromium/issues/detail?id=477783 Original issue's description: > Send resize event when the screen info changes. > > This is a regression from https://codereview.chromium.org/953233002 > > BUG=475939 > > Committed: https://crrev.com/6e3582ad1a058af30aa44ca7fae2113b050aa437 > Cr-Commit-Position: refs/heads/master@{#325494} TBR=danakj@chromium.org,jochen@chromium.org,piman@chromium.org,sadrul@chromium.org,sievers@chromium.org,mlamouri@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=475939 Review URL: https://codereview.chromium.org/1093713002 Cr-Commit-Position: refs/heads/master@{#325536}
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
…tchset #5 id:80001 of https://codereview.chromium.org/1082083005/) Reason for revert: Suspected of breaking the build. For details, see https://code.google.com/p/chromium/issues/detail?id=477869 Original issue's description: > [Chromoting] Enable remoting webapp main.html GN build. > > The previous remoting webapp GN build files were not enabled and at > least 6 months out of date. This cl fixes the problem by bringing > the build rules up to date and enables the webapp build. > > It also starts to move all the remoting-specific build rules into > the remoting dir rather than having them in the main build.gn file. > > BUG= > > Committed: https://crrev.com/62ee8a9cfebbc8bdc037aaa3b37ebfbb45e02472 > Cr-Commit-Position: refs/heads/master@{#325551} TBR=dpranke@chromium.org,garykac@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1090023004 Cr-Commit-Position: refs/heads/master@{#325556}
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
…tch(const char*). (patchset #5 id:80001 of https://codereview.chromium.org/1046363002/) Reason for revert: This causes test fails on Android: https://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg%29/builds/27294 The test uses upper case with HasSwitch(): https://code.google.com/p/chromium/codesearch#chromium/src/content/public/android/javatests/src/org/chromium/content/browser/ContentCommandLineTest.java&q=testJavaNativeTransition&sq=package:chromium&type=cs&l=96 Original issue's description: > Enforce lowercase switches when calling CommandLine::HasSwitch. > > At the moment, all compile-time switches are lowercase. By enforcing > this, we can skip converting it to lowercase on Windows, which saves > one string allocation per call. > > On a profile with 2 extensions, HasSwitch is called ~12k times during > startup. In an ideal situation (no paging/cache pressure), the > string allocation under Windows takes ~137ns on an Xeon E5-2690 @ > 2.9Ghz. So this should shave off at least 1.6ms off a typical startup > with this hardware. For context, > Startup.BrowserMessageLoopStartTimeFromMainEntry is typically > 280-300ms on the same hardware, so we should get a ~0.5% improvement. > > BUG=472383 > > Committed: https://crrev.com/f58961749a980032241fe6c3fc829ac2e6652030 > Cr-Commit-Position: refs/heads/master@{#325576} TBR=tapted@chromium.org,brettw@chromium.org,jackhou@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=472383 Review URL: https://codereview.chromium.org/1091993002 Cr-Commit-Position: refs/heads/master@{#325610}
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
…d:160001 of https://codereview.chromium.org/1077143002/) Reason for revert: Tentative revert to try to fix all the failing tests on https://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux%20MSAN/builds/2548 with stderrs like: ==22726== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7fb677cf3d50 in sandbox::Trap::SigSys(int, siginfo*, void*) sandbox/linux/seccomp-bpf/trap.cc:140:58 #1 0x7fb6744e3fcf in sandbox::sys_sigaction(int, sigaction const*, sigaction*) ???:0 Uninitialized value was created by an allocation of 'temp.lvalue49' in the stack frame of function '_ZN7sandbox7CodeGen6AppendEtjmm' #0 0x7fb677cf82b0 in sandbox::CodeGen::Append(unsigned short, unsigned int, unsigned long, unsigned long) sandbox/linux/bpf_dsl/codegen.cc:121:0 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/b/build/slave/WebKit_Linux_MSAN/build/src/out/Release/content_shell+0xef94d50) Exiting [22595:22595:0417/081926:1015885843:ERROR:command_buffer_proxy_impl.cc(166)] Could not send GpuCommandBufferMsg_Initialize. [22595:22595:0417/081926:1015885969:ERROR:webgraphicscontext3d_command_buffer_impl.cc(209)] CommandBufferProxy::Initialize failed. [4:4:0417/081926:1015885973:ERROR:command_buffer_proxy_impl.cc(166)] Could not send GpuCommandBufferMsg_Initialize. [22595:22595:0417/081926:1015886031:ERROR:webgraphicscontext3d_command_buffer_impl.cc(226)] Failed to initialize command buffer. [4:4:0417/081926:1015886209:ERROR:webgraphicscontext3d_command_buffer_impl.cc(209)] CommandBufferProxy::Initialize failed. [4:4:0417/081926:1015886330:ERROR:webgraphicscontext3d_command_buffer_impl.cc(226)] Failed to initialize command buffer. Original issue's description: > Introduce sys_sigprocmask and sys_sigaction. > > This is preparation of nacl_helper_nonsfi's secompbpf sandbox > implementation. > PNaCl toolchain's signal ABI is incompatible with Linux's. > For example, the length of sigset_t is shoter than Linux's. > (Android has also same problem). > siginfo_t has different memory layout. > Some signal numbers, including SIGBUS, SIGCHLD and SIGSYS, > or some signal flags are different. > This CL fills the gap, by introducing linux_signal.h and > two syscalls, sys_sigprocmask and sys_sigaction. > > Also, as signal.h provides ucontext_t, but PNaCl toolchain > does not provides ucontext_t, this CL re-use the > android_ucontext.h (by renaming it to linux_ucontext.h). > > TEST=Ran bots. > BUG=358465 > CQ_EXTRA_TRYBOTS=tryserver.chromium.linux:linux_chromium_trusty32_rel,linux_arm > > Committed: https://crrev.com/3a315e3246a5191cee27216c09e669ea2d6c33d3 > Cr-Commit-Position: refs/heads/master@{#325634} TBR=mdempsky@chromium.org,hidehiko@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=358465 Review URL: https://codereview.chromium.org/1093843002 Cr-Commit-Position: refs/heads/master@{#325644}
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
…7385 (patchset #5 id:80001 of https://codereview.chromium.org/1096593002/) Reason for revert: Speculative revert to try to fix linux_android_rel_ng trybots. Original issue's description: > Update mojo sdk to rev 8563c3d4162bd74e96783e823e076e99869d7385 > > R=jamesr@chromium.org, rockot@chromium.org > TBR=rockot@chromium.org > > Committed: https://crrev.com/a38136b7f2fd5a7a425bf06bc54c10741bfc22bd > Cr-Commit-Position: refs/heads/master@{#325643} TBR=jamesr@chromium.org,rockot@chromium.org,sky@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1063443006 Cr-Commit-Position: refs/heads/master@{#325714}
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
…atchset #5 id:80001 of https://codereview.chromium.org/1093883002/) Reason for revert: Causing compile failures: http://build.chromium.org/p/chromium.webkit/builders/WebKit%20Linux/builds/46775 http://build.chromium.org/p/chromium.webkit/builders/Linux%20ChromiumOS%20Builder/builds/66769 http://build.chromium.org/p/chromium.webkit/builders/GPU%20Mac%20Builder%20%28dbg%29/builds/33994 Original issue's description: > Reland Make a mojo:apptests GN meta-target, add apptests. > > Originally landed as https://codereview.chromium.org/1050233005/ > > Add test and apptest meta-targets in mojo/services/BUILD.gn. > Add most remaining test and apptest targets (clipboard, VM, WM). > (mojo shell apptests target is currently broken/no-op) > Allow debug, but exclude component and Mac configs as needed. > Rename and consolidate VM and WM apptest targets. > > BUG=NONE > TEST=Building mojo:apptests builds all local apptest binaries (on dbg too!). > R=sky@chromium.org > TBR=ben@chromium.org > > Committed: https://crrev.com/713b3a495380d37e0adf86a0ada837bb651156ec > Cr-Commit-Position: refs/heads/master@{#325711} TBR=ben@chromium.org,sky@chromium.org,msw@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=NONE Review URL: https://codereview.chromium.org/1072153003 Cr-Commit-Position: refs/heads/master@{#325720}
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
…076e99869d7385 (patchset #1 id:1 of https://codereview.chromium.org/1063443006/) Reason for revert: Speculatively try to fix the entire waterfall =( Original issue's description: > Revert of Update mojo sdk to rev 8563c3d4162bd74e96783e823e076e99869d7385 (patchset #5 id:80001 of https://codereview.chromium.org/1096593002/) > > Reason for revert: > Speculative revert to try to fix linux_android_rel_ng trybots. > > Original issue's description: > > Update mojo sdk to rev 8563c3d4162bd74e96783e823e076e99869d7385 > > > > R=jamesr@chromium.org, rockot@chromium.org > > TBR=rockot@chromium.org > > > > Committed: https://crrev.com/a38136b7f2fd5a7a425bf06bc54c10741bfc22bd > > Cr-Commit-Position: refs/heads/master@{#325643} > > TBR=jamesr@chromium.org,rockot@chromium.org,sky@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > > Committed: https://crrev.com/3c05e2000a4494ef0197022077ece8ff2bc7fe49 > Cr-Commit-Position: refs/heads/master@{#325714} TBR=jamesr@chromium.org,rockot@chromium.org,sky@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1098743002 Cr-Commit-Position: refs/heads/master@{#325721}
ryumiel
pushed a commit
that referenced
this issue
Apr 20, 2015
Change made is mainly for closing bug 464732. Detailed explanation please refer to bug 464732 comment #4 and #5. BUG=464732 Review URL: https://codereview.chromium.org/1061723002 Cr-Commit-Position: refs/heads/master@{#325725}
ryumiel
pushed a commit
that referenced
this issue
Apr 28, 2015
…ox encoder. (patchset #5 id:80001 of https://codereview.chromium.org/1084323005/) Reason for revert: Suspect of the following break: https://build.chromium.org/p/chromium.mac/builders/Mac10.9%20Tests/builds/1045 Log excerpt: VideoEncoderTest.EncodesVariedFrameSizes/3 (run #1): [ RUN ] VideoEncoderTest.EncodesVariedFrameSizes/3 ../../media/cast/sender/video_encoder_unittest.cc:375: Failure Value of: EncodeAndCheckDelivery(CreateTestVideoFrame(frame_size), frame_id, frame_id) Actual: true Expected: !is_testing_platform_encoder() Which is: false ... Original issue's description: > [cast] Handle frame size changes directly in the VideoToolbox encoder. > > To implement various kinds of re-initialization conditions more easily, > this CL subsumes responsibility for handling frame size changes directly > in the VideoToolbox encoder. > > The design is very similar to the previous one with a proxy encoder. > Instead of proxying the entire encoder, only the video frame factory is > proxied. Both the encoder and the proxy own a ref-counted reference to > the factory, which in turn owns a weak back-reference to the encoder and > a ref-counted reference to the current pixel buffer pool. > > When a frame size change is detected either by the encoder or by the > video frame factory, the internal compression session is reset. This is > done synchronously when executing on the Cast main thread, and by > posting a task to the cast main thread when not. > > The code to re-initialize the compression session will be re-used in > upcoming work where additional conditions, such as backgrounding, need > to be monitored for session reinitialization. > > BUG=1429234101 > > Committed: https://crrev.com/c7b0852e49ff8ffa05c91ee6d073815a047cd86f > Cr-Commit-Position: refs/heads/master@{#325878} TBR=miu@chromium.org,jfroy@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=1429234101 Review URL: https://codereview.chromium.org/1100583004 Cr-Commit-Position: refs/heads/master@{#325907}
ryumiel
pushed a commit
that referenced
this issue
Apr 28, 2015
…d lifetime mgmt in VideoCaptureBufferPool (patchset #7 id:480001 of https://codereview.chromium.org/1064963002/) Reason for revert: The reason for reverting is: Speculatively revert to address Android Tests (dbg) content_unittests failure: http://build.chromium.org/p/chromium.linux/builders/Android%20Tests%20%28dbg%29/builds/27395 content_unittests content_unittests failures: VideoCaptureBufferPoolTest.BufferPool/2 GpuMemoryBufferFactoryTests/GpuMemoryBufferFactoryTest.CreateAndDestroy/1 VideoCaptureBufferPoolTest.BufferPool/0 VideoCaptureBufferPoolTest.BufferPool/1 [ RUN ] VideoCaptureBufferPoolTest.BufferPool/0 [FATAL:browser_gpu_memory_buffer_manager.cc(56)] Check failed: !g_gpu_memory_buffer_manager. #00 0x764081d3 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00fdf1d3 #1 0x75cf95c3 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x008d05c3 #2 0x75a3c697 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00613697 #3 0x75f8d1fb /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00b641fb #4 0x75f8d35b /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00b6435b #5 0x75f8d3e3 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00b643e3 #6 0x75f8d5e3 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00b645e3 #7 0x75f8c3c7 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00b633c7 #8 0x75f49bb7 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00b20bb7 #9 0x75f41c8b /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00b18c8b #10 0x75736087 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x0030d087 #11 0x763de291 /data/app-lib/org.chromium.native_test-1/libcontent_unittests.so+0x00fb5291 #12 0x41503bcf /system/lib/libdvm.so+0x0001dbcf #13 0x41534125 /system/lib/libdvm.so+0x0004e125 #14 0x4150cfe3 /system/lib/libdvm.so+0x00026fe3 #15 0x41513fa3 /system/lib/libdvm.so+0x0002dfa3 #16 0x4151163b /system/lib/libdvm.so+0x0002b63b #17 0x41546863 /system/lib/libdvm.so+0x00060863 #18 0x4154e7c5 /system/lib/libdvm.so+0x000687c5 #19 0x4150cfe3 /system/lib/libdvm.so+0x00026fe3 #20 0x41513fa3 /system/lib/libdvm.so+0x0002dfa3 #21 0x4151163b /system/lib/libdvm.so+0x0002b63b #22 0x4154657f /system/lib/libdvm.so+0x0006057f #23 0x4152fd0d /system/lib/libdvm.so+0x00049d0d #24 0x401a82b3 /system/lib/libandroid_runtime.so+0x0004d2b3 #25 0x401a8fd9 /system/lib/libandroid_runtime.so+0x0004dfd9 #26 0x4006b05d /system/bin/app_process+0x0000105d #27 0x400a234b /system/lib/libc.so+0x0000e34b This CL is the most suspect in the blame-list because it touches the VideoCaptureBufferPool. Original issue's description: > VideoCapture: add support for GpuMemoryBuffer allocation and lifetime mgmt in VideoCaptureBufferPool & relatives > > - This CL adds support for GpuMemoryBufferTracker in > addition to the existing SharedMemTracker. > > - A GpuMemoryBufferTracker owns a GpuMemoryBuffer, > which can only be accessed byte-wise between Map() and > Unmap(). > > - For that reason, instead of making a VCBP::Tracker > directly accessible via |void* data| and |size|, a > BufferHandle abstraction is introduced. > > - VideoCaptureDeviceClient then defines its own > AutoReleaseBuffer in terms of this new BufferHandle. > This BufferHandle is supposed to stay Map()ed and > ready to use for the duration of its lifetime. > > Summing up: > * VideoCaptureBufferPool has a pool of Trackers, > * from the VCBP we can get a BufferHandle per |buffer_id|, > * from a BufferHandle we can obtain data(), valid > and Map()ed as long as the BufferHandle itself exists. > > - VideoCaptureDevice::ReserveOutputBuffer() changes to > return a scoped_ptr<Buffer> ISO a scoped_refptr. > > - Added VideoCaptureDevice::OnIncomingCapturedBuffer() > to pass directly a Buffer with the capture contents. > > - video_capture_texture_wrapper.{cc,h} is removed and > its contents are merged into VideoCaptureDeviceClient. > > - FakeVideoCaptureDevice learns how to produce > GpuMemoryBuffers. Also, PIXEL_FORMAT_GPUMEMORYBUFFER > is added. > > Summing up, VCDClient accepts: > * memory backed buffers (the usual) > * texture-backed buffers > * GMB-backed buffers (these are wrapped into a Texture > VideoFrame indistinguishable from the previous case) > > - VideoCaptureTextureWrapper files are gone and > its contents folded into VideoCaptureDeviceClient. > > - Unittests are updated, and so is FakeVideoCaptureDevice. > > BUG=440843 > > Committed: https://crrev.com/abeb15fa955c570cd481accb04c2a677eb2865a9 > Cr-Commit-Position: refs/heads/master@{#326171} TBR=miu@chromium.org,emircan@chromium.org,avi@chromium.org,dalecurtis@chromium.org,mcasas@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=440843 Review URL: https://codereview.chromium.org/1090273006 Cr-Commit-Position: refs/heads/master@{#326250}
ryumiel
pushed a commit
that referenced
this issue
Apr 28, 2015
…160001 of https://codereview.chromium.org/1077143002/) This CL is relanding the CL https://codereview.chromium.org/1077143002/, which was reverted due to false alarm of the memory sanitizer. Because the memory sanitizer does not know about direct kernel syscall does, so it warns the arguments of the signal handler, unexpectedly. This CL adds the msan unpoisoning to the arguemtns, so that the memory sanitizer should understand it. TEST=Ran sandbox_linux_unittests with msan=1. Ran bots. BUG=358465 CQ_EXTRA_TRYBOTS=tryserver.chromium.linux:linux_chromium_trusty32_rel,linux_arm Review URL: https://codereview.chromium.org/1092153005 Cr-Commit-Position: refs/heads/master@{#326270}
ryumiel
pushed a commit
that referenced
this issue
Apr 28, 2015
…atchset #1 id:1 of https://codereview.chromium.org/1099063003/) Reason for revert: Speculatively revert to address Linux ChromiumOS Tests browser_tests failure: http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%281%29/builds/1742 browser_tests RestoreOnStartupTestChromeOS.PRE_LogInAndVerify 596 disabled 10 flaky failed 2 failures: RestoreOnStartupTestChromeOS.LogInAndVerify RestoreOnStartupTestChromeOS.PRE_LogInAndVerify [385/509] RestoreOnStartupTestChromeOS.LogInAndVerify (SKIPPED) [ RUN ] RestoreOnStartupTestChromeOS.PRE_LogInAndVerify [ FATAL ] ../../testing/gtest/include/gtest/gtest.h:1849:: Condition parameter_ != NULL failed. GetParam() can only be called inside a value-parameterized test -- did you intend to write TEST_P instead of TEST_F? Received signal 6 #0 0x7ff3af22e6de base::debug::StackTrace::StackTrace() #1 0x7ff3af22e21f base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7ff3abc5dcb0 <unknown> #3 0x7ff3a78320d5 gsignal #4 0x7ff3a783583b abort #5 0x00000074f9d9 testing::internal::posix::Abort() #6 0x0000024055b0 testing::internal::GTestLog::~GTestLog() #7 0x0000007477b3 testing::WithParamInterface<>::GetParam() #8 0x0000012ecb31 policy::LoginPolicyTestBase::LoginPolicyTestBase() #9 0x0000012fc025 policy::RestoreOnStartupTestChromeOS::RestoreOnStartupTestChromeOS() #10 0x0000012fd18c policy::RestoreOnStartupTestChromeOS_PRE_LogInAndVerify_Test::RestoreOnStartupTestChromeOS_PRE_LogInAndVerify_Test() #11 0x0000012fd117 testing::internal::TestFactoryImpl<>::CreateTest() #12 0x0000007009ca _ZN7testing8internal12InvokeHelperIvNSt3tr15tupleIJEEEE12InvokeMethodIN10extensions42BluetoothPrivateApiTest_CancelPairing_TestEMNS7_23BluetoothPrivateApiTestEFvvEEEvPT_T0_RKS4_ #13 0x00000241ab2e testing::internal::HandleExceptionsInMethodIfSupported<>() #14 0x000002410383 testing::TestInfo::Run() #15 0x00000241094a testing::TestCase::Run() #16 0x000002415ccc testing::internal::UnitTestImpl::RunAllTests() #17 0x00000242c01a testing::internal::HandleSehExceptionsInMethodIfSupported<>() #18 0x00000241bf4e testing::internal::HandleExceptionsInMethodIfSupported<>() #19 0x00000241596f testing::UnitTest::Run() #20 0x0000022d95e1 RUN_ALL_TESTS() #21 0x0000022d8647 base::TestSuite::Run() #22 0x0000010d2b72 ChromeBrowserTestSuiteRunner::RunTestSuite() #23 0x00000224de78 (anonymous namespace)::ChromeTestLauncherDelegate::RunTestSuite() #24 0x000004c38ed5 content::LaunchTests() #25 0x00000224ddb9 LaunchChromeTests() #26 0x0000010d2ad8 main #27 0x7ff3a781d76d __libc_start_main #28 0x000000672fe9 <unknown> r8: 00007ff3a51dc8c0 r9: 00007ff3a51dc8c0 r10: 0000000000000008 r11: 0000000000000202 r12: 0000000000672fc0 r13: 00007fffdd71f330 r14: 0000000000000000 r15: 0000000000000000 di: 0000000000005662 si: 0000000000005662 bp: 00007fffdd71e270 bx: 0000000000000000 dx: 0000000000000006 ax: 0000000000000000 cx: ffffffffffffffff sp: 00007fffdd71e138 ip: 00007ff3a78320d5 efl: 0000000000000202 cgf: 0000000000000033 erf: 0000000000000000 trp: 0000000000000000 msk: 0000000000000000 cr2: 0000000000000000 Original issue's description: > Add browser test for RestoreOnStartup[URLs] on Chrome OS > > Ladies and gentlemen, this CL brings you the long-awaited end-to-end > browser test for RRestoreOnStartup and RestoreOnStartupURLs, at least > on Chrome OS. > > BUG=477145 > TEST=New browser test > > Committed: https://crrev.com/641bb06057cf18e518a96edaadaae42411341905 > Cr-Commit-Position: refs/heads/master@{#326261} TBR=mnissler@chromium.org,bartfab@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=477145 Review URL: https://codereview.chromium.org/1103493003 Cr-Commit-Position: refs/heads/master@{#326272}
ryumiel
pushed a commit
that referenced
this issue
Apr 28, 2015
…set #5 id:160001 of https://codereview.c… (patchset #4 id:80001 of https://codereview.chromium.org/1092153005/) Reason for revert: Causing Linux Tests to fail: http://build.chromium.org/p/chromium.linux/builders/Linux%20Tests%20%28dbg%29%281%29/builds/41533 sandbox_linux_unittests Trap.SigSysAction failed 14 failures: Syscall.SyntheticSixArgs SandboxBPF.PthreadEquality SandboxBPF.Pread64 SandboxBPF.UnsafeTrapWithErrno SandboxBPF.ForwardSyscall SandboxBPF.BasicBlacklistWithSigsys SandboxBPF.SigBus Trap.SigSysAction SandboxBPF.VerboseAPITesting ParameterRestrictions.sched_getparam_allowed SandboxBPF.UnsafeTrapWithCond [ RUN ] SandboxBPF.VerboseAPITesting ../../sandbox/linux/tests/unit_tests.cc:234: Failure Value of: subprocess_terminated_normally Actual: false Expected: true Original issue's description: > Reland: Introduce sys_sigprocmask and sys_sigaction. (patchset #5 id:160001 of https://codereview.chromium.org/1077143002/) > > This CL is relanding the CL https://codereview.chromium.org/1077143002/, > which was reverted due to false alarm of the memory sanitizer. > Because the memory sanitizer does not know about direct kernel syscall > does, so it warns the arguments of the signal handler, unexpectedly. > This CL adds the msan unpoisoning to the arguemtns, so that the memory > sanitizer should understand it. > > TEST=Ran sandbox_linux_unittests with msan=1. Ran bots. > BUG=358465 > CQ_EXTRA_TRYBOTS=tryserver.chromium.linux:linux_chromium_trusty32_rel,linux_arm > > Committed: https://crrev.com/c1c944e1ee0b100c9717084b50bdd697c6b308d2 > Cr-Commit-Position: refs/heads/master@{#326270} TBR=mdempsky@chromium.org,hidehiko@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=358465,479705 Review URL: https://codereview.chromium.org/1102543003 Cr-Commit-Position: refs/heads/master@{#326278}
ryumiel
pushed a commit
that referenced
this issue
Apr 28, 2015
… id:70001 of https://codereview.chromium.org/941453002/) Reason for revert: Speculative revert. This CL might be responsible for inverted text in omnibox. https://code.google.com/p/chromium/issues/detail?id=479097 Original issue's description: > mac: Tentative fix for Yosemite open file crash. > > There's a bug in AppKit that causes Chrome to crash when users attempt to save > or open a file. The code path that causes the crash is only hit by applications > linked against OSX 10.7 SDK (or earlier). This CL registers a default value for > the preference NSViewKeepLayersAround, which prevents this code path from being > hit. The functional implications of changing the preference > NSViewKeepLayersAround are minimal. > > BUG=428977 > > Committed: https://crrev.com/192b9d9cfe388a6cfb76b9aea56070da1d878a81 > Cr-Commit-Position: refs/heads/master@{#316968} TBR=andresantoso@chromium.org,avi@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=428977 Review URL: https://codereview.chromium.org/1104733002 Cr-Commit-Position: refs/heads/master@{#326585}
ryumiel
pushed a commit
that referenced
this issue
Apr 28, 2015
…tore exists. (patchset #5 id:120001 of https://codereview.chromium.org/1071553002/) Reason for revert: This appears to have made IndexedDBBrowserTest.DiskFullOnCommit flaky, starting at http://build.chromium.org/p/chromium.memory.fyi/builders/Windows%20Content%20Browser%20%28DrMemory%20full%29%20%286%29/builds/380 [ RUN ] IndexedDBBrowserTest.DiskFullOnCommit [1028:1768:0423/085845:4229748:INFO:mock_browsertest_indexed_db_class_factory.cc(258)] FailOperation: class=2, method=2, instanceNum=5, callNum=1 [1028:1768:0423/085845:4229873:INFO:indexed_db_browsertest.cc(77)] Navigating to URL and blocking. [3872:2724:0423/085859:4243383:ERROR:renderer_main.cc(200)] Running without renderer sandbox [1028:1096:0423/085958:4302491:ERROR:indexed_db_backing_store.cc(4197)] IndexedDB Write Error: TRANSACTION_COMMIT_METHOD [1028:1768:0423/090005:4309621:INFO:indexed_db_browsertest.cc(79)] Navigation done. c:\b\build\slave\drm-cr\build\src\content\browser\indexed_db\indexed_db_browsertest.cc(88): error: Failed Failed: Starting...<span>FAILED: unexpectedErrorCallback<br></span> [ FAILED ] IndexedDBBrowserTest.DiskFullOnCommit, where TypeParam = and GetParam() = (130664 ms) Original issue's description: > Optimizes the operation of DeleteDatabase when no backing store exists. > > When deleting the non existing database in a origin with no existing > backing store, then in DeleteDatabse(), early exiting before OpenBackingStore, > so that it wont results in multiple transaction as earlier. > > BUG=460236 > > Committed: https://crrev.com/a4c618a142515773709688bfe3c5753e589afd43 > Cr-Commit-Position: refs/heads/master@{#326473} TBR=cmumford@chromium.org,jsbell@chromium.org,payal.pandey@samsung.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=460236 Review URL: https://codereview.chromium.org/1106703003 Cr-Commit-Position: refs/heads/master@{#326686}
ryumiel
pushed a commit
that referenced
this issue
May 7, 2015
…s controller. Add logic to make sure that page sets paired with smoothness/repaint only have interaction records with same label & they have repeatable flags enabled. To make sure that this doesn't crash any smoothness benchmarks, I modified benchmark_smoke_unittest to run all smoothness benchmarks (including ones that only support android) in patch #3. To validate the test runs, see telemetry_perf_unittest's result in patch #5 smoothness.key_silk_cases: https://codereview.chromium.org/1111543002/ smoothness.polymer: https://codereview.chromium.org/1060583012 BUG=444701,444703 Review URL: https://codereview.chromium.org/1104573002 Cr-Commit-Position: refs/heads/master@{#327186}
ryumiel
pushed a commit
that referenced
this issue
May 7, 2015
…set #5 id:80001 of https://codereview.chromium.org/1062743006/) Reason for revert: Compilation errors that look related to the installer_util_strings.rc move: http://build.chromium.org/p/chromium/builders/Win/builds/31460 Original issue's description: > Add installer_util_unittests to the GN windows build > > This fixes some C++ Warnings on Windows to avoid having to add suppressions to the GN build. > > Moves the generated strings header to the same place in the gen tree as it is in the source tree. Update includes. > > CQ_EXTRA_TRYBOTS=tryserver.chromium.linux:android_chromium_gn_compile_dbg,android_chromium_gn_compile_rel;tryserver.chromium.win:win8_chromium_gn_rel,win8_chromium_gn_dbg;tryserver.chromium.mac:mac_chromium_gn_rel,mac_chromium_gn_dbg > > Committed: https://crrev.com/cb55755a09b9e2d8c5b05b7a4ad2ff8631e15b13 > Cr-Commit-Position: refs/heads/master@{#327790} TBR=dpranke@chromium.org,brettw@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1116263002 Cr-Commit-Position: refs/heads/master@{#327799}
ryumiel
pushed a commit
that referenced
this issue
May 7, 2015
…ved tests (patchset #2 id:60001 of https://codereview.chromium.org/1086863004/) Reason for revert: Breaks the memory sanitizer on CrOS: http://build.chromium.org/p/chromium.memory/builders/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/builds/981/steps/browser_tests/logs/DownloadNotificationTest.DownloadRemoved ================================================================= ==2998==ERROR: LeakSanitizer: detected memory leaks Indirect leak of 416 byte(s) in 1 object(s) allocated from: #0 0x5b583b in operator new(unsigned long) (/tmp/run_tha_testDL6ABE/out/Release/browser_tests+0x5b583b) #1 0x37f8977 in DownloadNotificationItem::DownloadNotificationItem(content::DownloadItem*, Profile*, DownloadNotificationItem::Delegate*) chrome/browser/download/notification/download_notification_item.cc:86:23 #2 0x3443434 in DownloadNotificationManager::OnNewDownloadReady(content::DownloadItem*) chrome/browser/download/notification/download_notification_manager.cc:45:11 #3 0x2e8993d in DownloadUIController::OnDownloadUpdated(content::DownloadManager*, content::DownloadItem*) chrome/browser/download/download_ui_controller.cc:146:3 #4 0x765f4df in content::DownloadItemImpl::UpdateObservers() content/browser/download/download_item_impl.cc:301:3 #5 0x7669506 in content::DownloadItemImpl::OnDownloadRenamedToIntermediateName(content::DownloadInterruptReason, base::FilePath const&) content/browser/download/download_item_impl.cc:1263:5 #6 0x7cf365c in Run base/callback.h:396:12 #7 0x7cf365c in MakeItSo base/bind_internal.h:293 #8 0x7cf365c in base::internal::Invoker\u003CIndexSequence\u003C0ul, 1ul>, base::internal::BindState\u003Cbase::Callback\u003Cvoid (content::DownloadInterruptReason, base::FilePath const&)>, void (content::DownloadInterruptReason, base::FilePath const&), base::internal::TypeList\u003Ccontent::DownloadInterruptReason, base::FilePath> >, base::internal::TypeList\u003Cbase::internal::UnwrapTraits\u003Ccontent::DownloadInterruptReason>, base::internal::UnwrapTraits\u003Cbase::FilePath> >, base::internal::InvokeHelper\u003Cfalse, void, base::Callback\u003Cvoid (content::DownloadInterruptReason, base::FilePath const&)>, base::internal::TypeList\u003Ccontent::DownloadInterruptReason const&, base::FilePath const&> >, void ()>::Run(base::internal::BindStateBase*) base/bind_internal.h:343 #9 0x3f18cc6 in Run base/callback.h:396:12 #10 0x3f18cc6 in base::debug::TaskAnnotator::RunTask(char const*, char const*, base::PendingTask const&) base/debug/task_annotator.cc:62 #11 0x3e336f7 in base::MessageLoop::RunTask(base::PendingTask const&) base/message_loop/message_loop.cc:444:3 #12 0x3e340df in base::MessageLoop::DeferOrRunPendingTask(base::PendingTask const&) base/message_loop/message_loop.cc:454:5 #13 0x3e34947 in base::MessageLoop::DoWork() base/message_loop/message_loop.cc:566:13 #14 0x3f12256 in HandleDispatch base/message_loop/message_pump_glib.cc:267:7 #15 0x3f12256 in base::(anonymous namespace)::WorkSourceDispatch(_GSource*, int (*)(void*), void*) base/message_loop/message_pump_glib.cc:109 #16 0x7f0a333dbd12 in g_main_dispatch /build/buildd/glib2.0-2.32.4/./glib/gmain.c:2539 #17 0x7f0a333dbd12 in g_main_context_dispatch /build/buildd/glib2.0-2.32.4/./glib/gmain.c:3075 Original issue's description: > [Download Notification] Add cancel-button and download-removed tests > > This patch adds the following tests: > - Clicking cancel-button while download is in progress > - Clicking cancel-button after download is finished > - Download is removed externally > > BUG=480489 > TEST=manually tested > > Committed: https://crrev.com/24185c2b385071c1ba007b3cc16f52692dd78d02 > Cr-Commit-Position: refs/heads/master@{#328059} TBR=asanka@chromium.org,yoshiki@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=480489 Review URL: https://codereview.chromium.org/1116923004 Cr-Commit-Position: refs/heads/master@{#328105}
ryumiel
pushed a commit
that referenced
this issue
May 7, 2015
…nderFrames. (patchset #5 id:80001 of https://codereview.chromium.org/1113393004/) Reason for revert: Causing failures on asan bots: https://build.chromium.org/p/chromium.memory/builders/Linux%20ASan%20LSan%20Tests%20%281%29/builds/13202/steps/content_browsertests/logs/stdio https://build.chromium.org/p/chromium.memory/builders/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/builds/1047/steps/content_browsertests/logs/stdio Original issue's description: > OOPIF: Specify previous sibling frames when creating RenderFrames. > > When initializing a new renderer for an OOP frame, the current > behavior is to first create all the RenderFrameProxies, and then to > create the new RenderFrame, appending it as its parent's last child in > the frame tree. This disregards the order of sibling frames and thus > may break indexed window access (e.g., window.frames[2]). > > This CL passes the previous sibling's routing ID in the > FrameMsg_NewFrame message, so that the new frame can be inserted in > the correct place in the frame tree. Note that we don't need to do > this for RenderFrameProxies, as those are already created in the > correct order (by CreateProxiesForSiteInstance) when initializing a > new renderer process. > > Corresponding Blink CL: https://codereview.chromium.org/1119823003/ > > BUG=478792 > > Committed: https://crrev.com/134cdb8c234847ebde156e46cad95be3221dc66b > Cr-Commit-Position: refs/heads/master@{#328384} TBR=nasko@chromium.org,alexmos@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=478792 Review URL: https://codereview.chromium.org/1118083004 Cr-Commit-Position: refs/heads/master@{#328419}
ryumiel
pushed a commit
that referenced
this issue
May 7, 2015
clear to developers. This commit includes 5 changes that make OIB connection info strings more clear to developers (and advanced users). Since it has become impractical to target "normal" users with these strings, the focus is on using exact terminology instead of "friendly" alternatives. This should help developers to understand the page's issues at a glance: https://docs.google.com/document/d/1YgavRvC7_6PoOYHjUuKQL1Mlc718z7F1AnTNGrM92W4/edit#heading=h.kldzb7b775ri Changes in this commit: 1. The identity section explicitly mentions when an error was caused by SHA-1 in the certificate chain, instead of referencing "outdated security settings" (there are no such settings apart from SHA-1 signatures right now). (https://crbug.com/437466) 2. Mentions of "public audit records" have been replaced with mentions of "Certificate Transparency". The phrase "Public audit records" was hinging at the implications of CT, but a full understanding the string requires knowledge of CT. Also, the mention of CT has been split into a separate sentence. The presence of "but" had a strong but incorrect implication that this affects the lock icon (which will not be the case for non-EV sites in the near future). 3. The phrase "modern cryptography" is now "modern cipher suite" in order to distinguish the kind of cryptography in question. (Similarly for "obsolete cryptography".) This technically doesn't mention the protocol; however, the main problem usually lies with the cipher suite rather than the protocol, and all the cipher suites we currently consider good require TLS 1.2 (or, say, QUIC) as a prerequisite. 4. Mixed content message: Instead of "However", the sentence now starts with "Further" so that it still makes sense when the protocol/cipher suite is obsolete (https://crbug.com/434617). 5. The "SHA1 for message authentication" string (for ciphers with a MAC) now displays SHA1 as HMAC-SHA1, to be more suggestive that this a different use of SHA-1 than for cert signatures. (Similarly for other TLS MACs.) Design constraint: In order to make this change as simple as possible, the code logic has not been touched. The string contents have been changed, but all strings keep their identifiers and semantics. Also, these changes are definitely meant as a band-aid. In the medium-long term, the plan is to remove the connection tab from the OIB and offer the information in DevTools. (However, we have yet to decide on a plan to supplant it on mobile.) Test pages: #1: https://sha1.badssl.com/ #2: - DV, no SCT: https://garron.net/ - DV, SCT: https://embed.ct.digicert.com/ - EV, no SCT: https://www.mozilla.org/ - EV, SCT: https://www.bankofamerica.com/ #3: - "modern": https://garron.net/ - "obsolete": https://rc4.badssl.com/ #4: https://mixed.badssl.com/ #5: https://rc4.badssl.com/ Note that this commit roughly coincides with the reintroduction of connection info on Android: - https://crbug.com/425158#c41 - https://chromium.googlesource.com/chromium/src/+/f21c52aeafa701b18ed505347ee0e7a7d07e5d53 Android Chrome users haven't been able to access this information for the last half year, and will see these new strings directly. BUG=461045, 434617, 437466 TEST=Visit the test pages (listed above). Review URL: https://codereview.chromium.org/1109283003 Cr-Commit-Position: refs/heads/master@{#328502}
ryumiel
pushed a commit
that referenced
this issue
May 7, 2015
…ing new RenderFrames. (patchset #1 id:1 of https://codereview.chromium.org/1118083004/) Reason for revert: The reason for the original revert was a leak caused by https://crbug.com/484760, and the relevant suppression was fixed in https://codereview.chromium.org/1130603002/. Original issue's description: > Revert of OOPIF: Specify previous sibling frames when creating new RenderFrames. (patchset #5 id:80001 of https://codereview.chromium.org/1113393004/) > > Reason for revert: > Causing failures on asan bots: > https://build.chromium.org/p/chromium.memory/builders/Linux%20ASan%20LSan%20Tests%20%281%29/builds/13202/steps/content_browsertests/logs/stdio > https://build.chromium.org/p/chromium.memory/builders/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/builds/1047/steps/content_browsertests/logs/stdio > > Original issue's description: > > OOPIF: Specify previous sibling frames when creating RenderFrames. > > > > When initializing a new renderer for an OOP frame, the current > > behavior is to first create all the RenderFrameProxies, and then to > > create the new RenderFrame, appending it as its parent's last child in > > the frame tree. This disregards the order of sibling frames and thus > > may break indexed window access (e.g., window.frames[2]). > > > > This CL passes the previous sibling's routing ID in the > > FrameMsg_NewFrame message, so that the new frame can be inserted in > > the correct place in the frame tree. Note that we don't need to do > > this for RenderFrameProxies, as those are already created in the > > correct order (by CreateProxiesForSiteInstance) when initializing a > > new renderer process. > > > > Corresponding Blink CL: https://codereview.chromium.org/1119823003/ > > > > BUG=478792 > > > > Committed: https://crrev.com/134cdb8c234847ebde156e46cad95be3221dc66b > > Cr-Commit-Position: refs/heads/master@{#328384} > > TBR=nasko@chromium.org,alexmos@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=478792 > > Committed: https://crrev.com/e94c7ac058b50b1771a644b2d85652b725367bbd > Cr-Commit-Position: refs/heads/master@{#328419} TBR=nasko@chromium.org,piman@chromium.org BUG=478792 Review URL: https://codereview.chromium.org/1131593003 Cr-Commit-Position: refs/heads/master@{#328591}
ryumiel
pushed a commit
that referenced
this issue
May 11, 2015
…id:80001 of https://codereview.chromium.org/1106153002/) Reason for revert: The smart bubble isn't gonna happen in M44. There is no reason to make these unnecessary requests. Original issue's description: > PaswordFormManager should fetch the site stats. > > ManagePasswordsUIController will be extended in the future to write the stats. > > BUG=431739 > > Committed: https://crrev.com/0ff4c141dab88f9cca01a21b790b2a767b462ff2 > Cr-Commit-Position: refs/heads/master@{#327973} TBR=vabr@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=431739 Review URL: https://codereview.chromium.org/1135643003 Cr-Commit-Position: refs/heads/master@{#328862}
ryumiel
pushed a commit
that referenced
this issue
May 11, 2015
…103 now supplies this file (patchset #5 id:80001 of https://codereview.chromium.org/1131153002/) Reason for revert: Broke Win8 GN build. http://build.chromium.org/p/chromium.win/builders/Win8%20GN/builds/7036/steps/compile/logs/stdio Original issue's description: > Include inttypes.h unconditionally in format_macros.h - VS2103 now supplies this file > > BUG= > > Committed: https://crrev.com/ffb6b7c8e0599f6fb3b25bbd5bc49b5fba818ffd > Cr-Commit-Position: refs/heads/master@{#328894} TBR=scottmg@chromium.org,thakis@chromium.org,chcunningham@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1123983003 Cr-Commit-Position: refs/heads/master@{#328898}
ryumiel
pushed a commit
that referenced
this issue
May 11, 2015
… SocketDataProvider (patchset #5 id:80001 of https://codereview.chromium.org/1114383003/) Reason for revert: Even this revised patch seems to break on iOS. http://build.chromium.org/p/chromium.mac/builders/iOS_Simulator_%28dbg%29/builds/26548/steps/net_unittests%20%28iPhone%205%20iOS%208.1%29/logs/stdio WTF!?!?!?!!? Original issue's description: > Add AllReadDataConsumed and AllWriteDataConsumed methods to SocketDataProvider > so that all provider subclasses can have their state verified. > > Committed: https://crrev.com/bce10d97d6fc5233071427cf622aaad7abde9e19 > Cr-Commit-Position: refs/heads/master@{#328154} > > Committed: https://crrev.com/269875cf0d23881a7ad119bae730ff54fdd4dd0b > Cr-Commit-Position: refs/heads/master@{#328351} > > Committed: https://crrev.com/d833a674a5e4f3b4e47f229b3d5411a8d509c2c0 > Cr-Commit-Position: refs/heads/master@{#328909} TBR=rtenneti@chromium.org,sergeyu@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/1123383004 Cr-Commit-Position: refs/heads/master@{#328922}
ryumiel
pushed a commit
that referenced
this issue
May 11, 2015
#5 id:80001 of https://codereview.chromium.org/1106673002/) Reason for revert: This breaks some tests on the site isolation bots. Original issue's description: > Swap the main frame in --site-per-process mode too. > > Calling swap() is required to set up a lot of required state in Blink > for the WebRemoteFrame. Without this, bad things happen. > > BUG=475003 > > Committed: https://crrev.com/9463868c8a2d30b6a81db9fd2b61e8a5935ac347 > Cr-Commit-Position: refs/heads/master@{#329012} TBR=creis@chromium.org,nasko@chromium.org,alexmos@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=475003 Review URL: https://codereview.chromium.org/1137833002 Cr-Commit-Position: refs/heads/master@{#329024}
ryumiel
pushed a commit
that referenced
this issue
May 18, 2015
…ositive switch from snapping to docking (patchset #5 id:90001 of https://codereview.chromium.org/1127133003/) Reason for revert: I suspect this is causing a browser_tests failure on the bots: http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/2069 https://build.chromium.org/p/chromium.webkit/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/1913 Sorry! Original issue's description: > Adjusts dragging logic to be less likely to trigger false positive switch from > snapping to docking. > > This CL adjusts the logic which selects whether a window will be snapped to > half of the workspace width or will be docked at the end of the drag when the > window is dragged to the edge of the workspace in the special case of the dock > being visible. The CL makes it easier to snap a window to half the workspace > width in this special case (and harder to inadvertently dock the window) > > BUG=484877 > TEST=None > > Committed: https://crrev.com/988c697aff35b3fd347dec35f2f2ac159c8328a9 > Cr-Commit-Position: refs/heads/master@{#329268} TBR=pkotwicz@chromium.org,varkha@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=484877 Review URL: https://codereview.chromium.org/1128933005 Cr-Commit-Position: refs/heads/master@{#329301}
ryumiel
pushed a commit
that referenced
this issue
May 18, 2015
…(patchset #2 id:20001 of https://codereview.chromium.org/1127383007/) Reason for revert: This has caused failures on the memory bots. e.g.:http://build.chromium.org/p/chromium.memory.fyi/builders/Linux%20MSan%20Tests/builds/6179 Sample test output: [ RUN ] TouchSelectionControllerTest.AllowShowingFromCurrentSelection ==6485== WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7f5bc93bb605 in ui::TouchSelectionController::OnSelectionBoundsChanged(ui::SelectionBound const&, ui::SelectionBound const&) ui/touch_selection/touch_selection_controller.cc:71:27 #1 0x7f5bc922803a in ui::TouchSelectionControllerTest::ChangeSelection(gfx::RectF const&, bool, gfx::RectF const&, bool) ui/touch_selection/touch_selection_controller_unittest.cc:147:5 #2 0x7f5bc9278c8d in ui::TouchSelectionControllerTest_AllowShowingFromCurrentSelection_Test::TestBody() ui/touch_selection/touch_selection_controller_unittest.cc:946:3 #3 0x7f5bc93631dc in HandleExceptionsInMethodIfSupported\u003Ctesting::Test, void> testing/gtest/src/gtest.cc:2420:12 #4 0x7f5bc93631dc in testing::Test::Run() testing/gtest/src/gtest.cc:2436:0 #5 0x7f5bc9365a4c in testing::TestInfo::Run() testing/gtest/src/gtest.cc:2612:5 #6 0x7f5bc93673f6 in testing::TestCase::Run() testing/gtest/src/gtest.cc:2730:5 #7 0x7f5bc9384d03 in testing::internal::UnitTestImpl::RunAllTests() testing/gtest/src/gtest.cc:4602:11 #8 0x7f5bc9383ce2 in HandleExceptionsInMethodIfSupported\u003Ctesting::internal::UnitTestImpl, bool> testing/gtest/src/gtest.cc:2420:12 #9 0x7f5bc9383ce2 in testing::UnitTest::Run() testing/gtest/src/gtest.cc:4220:0 #10 0x7f5bc93078a3 in RUN_ALL_TESTS testing/gtest/include/gtest/gtest.h:2326:10 #11 0x7f5bc93078a3 in base::TestSuite::Run() base/test/test_suite.cc:228:0 #12 0x7f5bc92f7b2d in (anonymous namespace)::RunTestSuite(int, char**) base/test/run_all_unittests.cc:25:10 #13 0x7f5bc92f85ee in Run base/callback.h:396:12 #14 0x7f5bc92f85ee in base::(anonymous namespace)::LaunchUnitTestsInternal(base::Callback\u003Cint ()> const&, int, bool, base::Callback\u003Cvoid ()> const&) base/test/launcher/unit_test_launcher.cc:184:0 #15 0x7f5bc92f7f5b in base::LaunchUnitTests(int, char**, base::Callback\u003Cint ()> const&) base/test/launcher/unit_test_launcher.cc:423:10 #16 0x7f5bc92f792d in main base/test/run_all_unittests.cc:37:10 #17 0x7f5bc206a76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226:0 #18 0x7f5bc9188f38 in _start ??:0:0 Uninitialized value was created by a heap allocation #0 0x7f5bc91da0e2 in operator new(unsigned long) ??:0:0 #1 0x7f5bc927c95c in ui::TouchSelectionControllerTest::SetUp() ui/touch_selection/touch_selection_controller_unittest.cc:65:23 #2 0x7f5bc9362f57 in HandleExceptionsInMethodIfSupported\u003Ctesting::Test, void> testing/gtest/src/gtest.cc:2420:12 #3 0x7f5bc9362f57 in testing::Test::Run() testing/gtest/src/gtest.cc:2432:0 #4 0x7f5bc9365a4c in testing::TestInfo::Run() testing/gtest/src/gtest.cc:2612:5 #5 0x7f5bc93673f6 in testing::TestCase::Run() testing/gtest/src/gtest.cc:2730:5 #6 0x7f5bc9384d03 in testing::internal::UnitTestImpl::RunAllTests() testing/gtest/src/gtest.cc:4602:11 #7 0x7f5bc9383ce2 in HandleExceptionsInMethodIfSupported\u003Ctesting::internal::UnitTestImpl, bool> testing/gtest/src/gtest.cc:2420:12 #8 0x7f5bc9383ce2 in testing::UnitTest::Run() testing/gtest/src/gtest.cc:4220:0 #9 0x7f5bc93078a3 in RUN_ALL_TESTS testing/gtest/include/gtest/gtest.h:2326:10 #10 0x7f5bc93078a3 in base::TestSuite::Run() base/test/test_suite.cc:228:0 #11 0x7f5bc92f7b2d in (anonymous namespace)::RunTestSuite(int, char**) base/test/run_all_unittests.cc:25:10 #12 0x7f5bc92f85ee in Run base/callback.h:396:12 #13 0x7f5bc92f85ee in base::(anonymous namespace)::LaunchUnitTestsInternal(base::Callback\u003Cint ()> const&, int, bool, base::Callback\u003Cvoid ()> const&) base/test/launcher/unit_test_launcher.cc:184:0 #14 0x7f5bc92f7f5b in base::LaunchUnitTests(int, char**, base::Callback\u003Cint ()> const&) base/test/launcher/unit_test_launcher.cc:423:10 #15 0x7f5bc92f792d in main base/test/run_all_unittests.cc:37:10 #16 0x7f5bc206a76c in __libc_start_main /build/buildd/eglibc-2.15/csu/libc-start.c:226:0 SUMMARY: MemorySanitizer: use-of-uninitialized-value (/mnt/data/b/build/slave/Linux_MSan_Tests/build/src/out/Release/ui_touch_selection_unittests+0x285605) Exiting Original issue's description: > Be explicit about forcing TouchSelectionController updates > > Previously, cached values in the TouchSelectionController would be reset > to force future selection updates. However, these cached values can > actually be used outside of selection update calls, e.g., when force > showing the selection from the current cached values. Instead of > resetting the cached values, simply set a dirty bit that forces an > update, avoiding issues when dealing with the reset values. > > BUG=393025 > > Committed: https://crrev.com/fdcf817da49ee92fe191981f7525503444f75f83 > Cr-Commit-Position: refs/heads/master@{#329325} TBR=mohsen@chromium.org,jdduke@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=393025 Review URL: https://codereview.chromium.org/1139533006 Cr-Commit-Position: refs/heads/master@{#329352}
ryumiel
pushed a commit
that referenced
this issue
May 18, 2015
…er false positive switch from snapping to docking (patchset #1 id:1 of https://codereview.chromium.org/1128933005/) Reason for revert: This revert probably did not fix the flakiness. I suspect that a revert that actually ended up fixing the bots is this: https://codereview.chromium.org/1139943002. I will re-land my original change. Original issue's description: > Revert of Adjusts dragging logic to be less likely to trigger false positive switch from snapping to docking (patchset #5 id:90001 of https://codereview.chromium.org/1127133003/) > > Reason for revert: > I suspect this is causing a browser_tests failure on the bots: > > http://build.chromium.org/p/chromium.chromiumos/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/2069 > https://build.chromium.org/p/chromium.webkit/builders/Linux%20ChromiumOS%20Tests%20%28dbg%29%281%29/builds/1913 > > Sorry! > > Original issue's description: > > Adjusts dragging logic to be less likely to trigger false positive switch from > > snapping to docking. > > > > This CL adjusts the logic which selects whether a window will be snapped to > > half of the workspace width or will be docked at the end of the drag when the > > window is dragged to the edge of the workspace in the special case of the dock > > being visible. The CL makes it easier to snap a window to half the workspace > > width in this special case (and harder to inadvertently dock the window) > > > > BUG=484877 > > TEST=None > > > > Committed: https://crrev.com/988c697aff35b3fd347dec35f2f2ac159c8328a9 > > Cr-Commit-Position: refs/heads/master@{#329268} > > TBR=pkotwicz@chromium.org,varkha@chromium.org > NOPRESUBMIT=true > NOTREECHECKS=true > NOTRY=true > BUG=484877 > > Committed: https://crrev.com/0d4f7d597774f7415f1aff374db498c8fbe88a9a > Cr-Commit-Position: refs/heads/master@{#329301} TBR=pkotwicz@chromium.org,dpranke@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=484877 Review URL: https://codereview.chromium.org/1140733002 Cr-Commit-Position: refs/heads/master@{#329413}
ryumiel
pushed a commit
that referenced
this issue
May 18, 2015
…80001 of https://codereview.chromium.org/1132013004/) Reason for revert: Failing on valgrind bots Original issue's description: > [Sync] Refactoring polling to be reliable. > > Polling is now an important component of sync health, as it can sometimes be > the only time we'll query for certain datatypes. As such, the following > has changed: > - Polls that fail will be retried (with backoff). > - As such, the logic to force a poll after an auth error isn't needed anymore > - The last successful poll time will be persisted in the sync prefs. > - On startup, schedule the first poll for last_poll_time + poll_interval > (or Now(), whichever is latest). > - Receiving a new poll interval from the server will update the poll timer > - The poll timer is now a one shot timer, and only restarts on success > - Some code cleanup to make the above more straightforward > > BUG=482154 > > Committed: https://crrev.com/3777d8727d7b4caedfb72bfdcbe2fea1f1d1d594 > Cr-Commit-Position: refs/heads/master@{#329669} TBR=pavely@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=482154 Review URL: https://codereview.chromium.org/1144443004 Cr-Commit-Position: refs/heads/master@{#329683}
ryumiel
pushed a commit
that referenced
this issue
May 18, 2015
StartSrpcServices will require using the service_runtime pointer, to set up the srpc_client pointer. So we cannot destroy the service_runtime at the same time. E.g., if I add a sleep() to induce the race, I get: ../../native_client/src/include/nacl_scoped_ptr.h:96: C *nacl::scoped_ptr<plugin::SelLdrLauncherChrome>::operator->() const [C = plugin::SelLdrLauncherChrome]: Assertion `ptr_ != __null' failed. Received signal 6 #0 0x7f687f4aef7e base::debug::StackTrace::StackTrace() #1 0x7f687f4aeabf base::debug::(anonymous namespace)::StackDumpSignalHandler() #2 0x7f6879dee340 <unknown> #3 0x7f6876504cc9 gsignal #4 0x7f68765080d8 abort #5 0x7f68764fdb86 <unknown> #6 0x7f68764fdc32 __assert_fail #7 0x7f688e2887f2 nacl::scoped_ptr<>::operator->() #8 0x7f688e288487 plugin::ServiceRuntime::SetupAppChannel() #9 0x7f688e28cb76 plugin::NaClSubprocess::StartSrpcServices() #10 0x7f688e281810 plugin::PnaclTranslateThread::DoLink() #11 0x7f688e27fe7d plugin::PnaclTranslateThread::DoLinkThread() #12 0x7f6879de6182 start_thread #13 0x7f68765c847d clone Should have checked this in previous refactoring: https://codereview.chromium.org/1128943003 BUG=473474 Review URL: https://codereview.chromium.org/1128373005 Cr-Commit-Position: refs/heads/master@{#329718}
ryumiel
pushed a commit
that referenced
this issue
May 18, 2015
…(patchset #5 id:80001 of https://codereview.chromium.org/1139543002/) Reason for revert: Syntax error in the JS, breaking the closure bot and almost surely doesn't work well/breaking something in remoting. http://build.chromium.org/p/chromium.fyi/builders/Closure%20Compilation%20Linux/builds/22330/steps/compile/logs/stdio Original issue's description: > [Chromoting] Show any startup errors in the LoadingWindow. > > Show any connection errors during startup in the LoadingWindow rather > than creating a new error window for the error. > > This cl also adds a new updateErrorMessage method to the MessageWindow > to update the message and reset the message window as appropriate for > an error message (disabling the spinner, updating the button label). > > BUG= > > Committed: https://crrev.com/d44e8a774ce99a89c350d10d5b3f9f644eb0c3d1 > Cr-Commit-Position: refs/heads/master@{#330022} TBR=jamiewalch@chromium.org,garykac@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG= Review URL: https://codereview.chromium.org/1144593002 Cr-Commit-Position: refs/heads/master@{#330052}
ryumiel
pushed a commit
that referenced
this issue
May 19, 2015
…rtup (patchset #5 id:160001 of https://codereview.chromium.org/1129953004/) Reason for revert: Massive data race reports, see https://crbug.com/489263 Original issue's description: > Reland: Lazily initialize MessageLoop for faster thread startup > > Original review: https://codereview.chromium.org/1011683002/ > > Reverted because it's suspected for following flakiness issues: > http://crbug.com/485157 - Windows race > http://crbug.com/485091 - Android ThreadWatcher > http://crbug.com/485178 - interactive_ui_tests Menu* tests > > PS1 is the original patch set that gets reverted. > > BUG=465458, 485157, 485091, 485178 > TBR=jam > > Committed: https://crrev.com/8b6133a69f16702a32a3c3104630c4d9ac393b7a > Cr-Commit-Position: refs/heads/master@{#330329} TBR=thakis@chromium.org,toyoshim@chromium.org,jam@chromium.org,kinuko@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=465458, 485157, 485091, 485178 Review URL: https://codereview.chromium.org/1140363002 Cr-Commit-Position: refs/heads/master@{#330351}
ryumiel
pushed a commit
that referenced
this issue
May 22, 2015
…01 of https://codereview.chromium.org/1149813002/) Reason for revert: Broke windows build. Original issue's description: > Changes caching logic of mojo java apps > > Previously we would extract all necessary files every time we ran the > app. This is obviously unnecessary for any bundled apps. Now we > extract only as necessary. > > R=ben@chromium.org, jcivelli@chromium.org > BUG=none > TEST=none > > Committed: https://crrev.com/128f7a0181634a89a35f681baab1d086d100e377 > Cr-Commit-Position: refs/heads/master@{#330824} TBR=ben@chromium.org,jcivelli@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=none Review URL: https://codereview.chromium.org/1147203002 Cr-Commit-Position: refs/heads/master@{#330832}
For the approach provided at #12 this is an issue that can no longer happen. |
ltilve
pushed a commit
that referenced
this issue
Sep 14, 2015
…(Sub)TextureCHROMIUM. (patchset #10 id:200001 of https://codereview.chromium.org/1275773003/ ) Reason for revert: Linux AMD GPU FYI bot has a broken gl_tests, likely because of this patch. http://build.chromium.org/p/chromium.gpu.fyi/builders/Linux%20Release%20%28ATI%29/builds/41273 [ RUN ] GLCopyTextureCHROMIUMTests/GLCopyTextureCHROMIUMTest.Basic/2 Received signal 11 SEGV_MAPERR 000000000045 #0 0x000000492795 base::debug::(anonymous namespace)::StackDumpSignalHandler() #1 0x7ff52630acb0 <unknown> #2 0x7ff5232a858c <unknown> #3 0x7ff5230a247c <unknown> #4 0x7ff5230a33ae <unknown> #5 0x7ff5227e8585 <unknown> #6 0x7ff5227e9b0a <unknown> #7 0x7ff522bf75c3 <unknown> #8 0x0000004f7ba4 gfx::GLApiBase::glCopyTexImage2DFn() #9 0x000000596ac1 (anonymous namespace)::DoCopyTexImage2D() #10 0x0000005968c4 gpu::CopyTextureCHROMIUMResourceManager::DoCopyTexture() Original issue's description: > gpu: support GL_TEXTURE_CUBE_MAP destination target to Copy(Sub)TextureCHROMIUM. > > It makes it possible to optimize WebGL. > > TEST=gl_tests GLCopyTextureCHROMIUMTests/GLCopyTextureCHROMIUMTest.* > BUG=517548 > > Committed: https://crrev.com/fa25f0e5786527e63c6ff9aeda77da3bd7456ee3 > Cr-Commit-Position: refs/heads/master@{#347354} TBR=piman@chromium.org,sievers@chromium.org,kbr@chromium.org,zmo@chromium.org,dongseong.hwang@intel.com NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=517548,528374 Review URL: https://codereview.chromium.org/1304103005 Cr-Commit-Position: refs/heads/master@{#347465}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Using the chrome.tabs API to iterate through the available tabs to toggle the sidebar at all of them, it also shows it at the devTools window, when this is detached. It might be a good idea to avoid allowing sidebars at the DevTools, as there is already an specific chrome.devtools.panels API for that.
The text was updated successfully, but these errors were encountered: