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

Issue 726218 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
NOT IN USE
Closed: Sep 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 678879



Sign in to add a comment

New LayoutTests for inert reveal existing memory leak

Project Member Reported by aboxhall@chromium.org, May 25 2017

Issue description

These three tests:

fast/dom/inert/inert-node-is-uneditable.html
fast/dom/inert/inert-inlines.html
fast/dom/inert/inert-label-focus.html

added in https://codereview.chromium.org/2088453002/, caused a leak to be detected: https://bugs.chromium.org/p/chromium/issues/detail?id=725815

However, running these tests on a clean build without the other changes in that patch set indicates that they have revealed one or more existing leaks, rather than the new code introducing a leak.
 

Comment 1 by kouhei@chromium.org, May 25 2017

Cc: yosin@chromium.org
Components: Blink>Editing
Owner: hajimehoshi@chromium.org

Comment 2 by yosin@chromium.org, May 26 2017

Components: -Blink>Editing
Owner: ----

Comment 3 by yosin@chromium.org, May 26 2017

Editing isn't related to this leak.
Cc: hajimehoshi@chromium.org
Blockedon: 678879
Components: -Blink>DOM Blink>Input
Owner: lanwei@chromium.org
Status: Available (was: Untriaged)
https://bugs.chromium.org/p/chromium/issues/detail?id=678879 might be related. lanwei@, could you take a look?
Labels: -Pri-3 Pri-2

Comment 7 by lanwei@chromium.org, May 31 2017

We have used pointerActionSequence in layout tests, and we did not see memory leak, but  I will take a look.
Minimized test case to cause leaks:

<!DOCTYPE html>
<script>
var pointerActions = [{
    source: "mouse",
    actions: [
        { name: "pointerMove", x: 0, y: 0 },
    ]
}];
for (var i = 0; i < 3; i++) {
    chrome.gpuBenchmarking.pointerActionSequence(pointerActions);
}
</script>

Cc: lanwei@chromium.org
Owner: hajimehoshi@chromium.org
Status: Started (was: Available)
I investigated this and found this is probably not a real leak.

* chrome.gpuBenchmarking.pointerActionSequence enqueues a gesture and its callback at RenderWidget::QueueSyntheticGesture.
* Callbacks are enqueued to RenderWiedget::pending_synthetic_gesture_callbacks_.
* Callbacks refers its V8 context, that refers a document.
* Callbacks are dequeued when InputMsg_SyntheticGestureCompleted.
* The leak detector tries to detect before all the callbacks are consumed. Actually, when GC is delayed by like 1 second, this leak doesn't happen.

Thus, I think we should fix the leak detector to wait all the callbacks are consumed.

Comment 10 by r...@opera.com, Sep 26 2017

I got a change reverted because I hit this leak. Presubmit enforces the use of pointerActionSequence instead of eventSender for interactive tests which is unfortunate as long as this issue is not fixed.

Comment 11 by r...@opera.com, Sep 26 2017

Blocking: 768790
rune@: As this leak is false positive, you can add your test to LeakExpectations and go ahead if you need.
Cc: r...@opera.com dtapu...@chromium.org
Owner: aboxhall@chromium.org
I looked at these tests and they aren't awaiting for the promise to be resolved which is causing the leak (and actually failing to actually test anything).

You should either use an async test. Or await on the promise.
Appears you can't await inside a sync test; so really these should be async tests. You may need to daisy chain them as you don't want them all running at once since you are clicking on items.
You should be able to use a promise_test instead of a test and return the promise from the method.
Components: -Blink>Input Blink>DOM
moving to Blink>DOM since this is an issue with the layouttests

Comment 17 by r...@opera.com, Sep 27 2017

Blocking: -768790

Comment 19 by r...@opera.com, Sep 27 2017

Cc: aboxhall@chromium.org
Owner: r...@opera.com
Status: Fixed (was: Started)
Awesome, thank you for fixing!

Sign in to add a comment