Skip to content
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

Closed
ltilve opened this issue Apr 17, 2015 · 1 comment
Closed

Sidebar visible at detached DevTools window #5

ltilve opened this issue Apr 17, 2015 · 1 comment

Comments

@ltilve
Copy link
Owner

ltilve commented Apr 17, 2015

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.

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}
@ltilve
Copy link
Owner Author

ltilve commented May 25, 2015

For the approach provided at #12 this is an issue that can no longer happen.

@ltilve ltilve closed this as completed May 25, 2015
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
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant