New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 859506 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 11
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

DCHECK in views_unittests.MenuControllerTest.AsynchronousGestureDeletesController

Reported by vladbe...@yandex-team.ru, Jul 2

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 YaBrowser/18.4.1.868 Yowser/2.5 Safari/537.36

Steps to reproduce the problem:
1. Run the test
2. Move mouse during the test running

What is the expected behavior?
The test works.

What went wrong?
The test failed on the DCHECK: Check failed: IsValidTimebase(now, *timestamp). Event timestamp (268423803916 bogo-microseconds) is not consistent with current time (2000 bogo-microseconds).

Did this work before? N/A 

Chrome version: 65.0.3325.181  Channel: dev
OS Version: OS X 10.12.6
Flash Version: Shockwave Flash 26.0 r0

It happens because MenuControllerTest uses EventGenerator that overrides EventTimeForNow. The event time for NSEvent* is calculated from its timestamp, not from overrided values. It happens only on macOS because only there views::test::WaitForMenuClosureAnimation() runs a RunLoop (where events are processed).

It seems user manipulations shouldn't affect unittests (since it's not integration tests), especially to allow to run them simultaneously.
 
Labels: Needs-Milestone
Components: Blink>ViewSource
Cc: sindhu.chelamcherla@chromium.org
Components: Internals>Views
Labels: TE-NeedsTriageHelp
This seems to be out of scope of TE as this is related to Dcheck in views. Tentatively adding Internal>Views label for further triaging from dev team.

Thanks!
Cc: tapted@chromium.org
Yeah, user interaction shouldn't affect unit tests, but I'm unsure about the exact defect.
Trent, do you know what might be going wrong here?
Cc: ellyjo...@chromium.org
this is from r550160 

I don't think we want to change the NSEvent -> ui::Event mapping so that incorporates ui::EventTimeForNow().

Also, I don't think we can "ban" unittests from spinning run loops (where it's inevitable that any OS-generated event will be seen). Nor would we want to attempt to block OS-generated events.

TBH, I think this is working fine.

We can possibly tweak the way animation-disablement works, and not invoke WaitForMenuClosureAnimation().

Or we can do "fancy" animations like wm::CrossFadeAnimation which work by "snapshotting" the layer tree in the window and moving ownership into a non-Widget.
Status: WontFix (was: Unconfirmed)
This test doesn't DCHECK under the test conditions for me, and it sounds from #5 like the behavior under test is WAI anyway. WontFix.

Sign in to add a comment