1169146 - Pressing the 'Clear' button while recording makes it impossible to start another recording without reopening the toolbox

Status: VERIFIED FIXED

(DevTools :: Performance Tools (Profiler/Timeline), defect)

Description

[Sami Jaktholm]

STR:
1. Open performance tool.
2. Start recording.
3. Press 'Clear' button. The active recording stops.
4. Press the 'Start Recording Performance' button again.

Expected: A new recording starts.
Actual: The button is disabled but a recording is never started. The toolbox needs to be reopened before another recording can start.

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: 1169146-recordingbutton-clear.patch

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a4cb413a4277

Comment 3

[Victor Porof [:vporof][:vp]]

Comment on attachment 8617695 [details] [diff] [review]
1169146-recordingbutton-clear.patch

Review of attachment 8617695 [details] [diff] [review]:
-----------------------------------------------------------------

oops

::: browser/devtools/performance/performance-view.js
@@ +182,5 @@
> +   * on `shouldLock`.
> +   *
> +   * @param {boolean} shouldLock
> +   */
> +  _lockRecordButtons: function (shouldLock) {

"lock" vs. "shouldLock" is confusing.

_setRecordingButtonsLockedState is a mouthful but much clearer.

@@ +201,2 @@
>     */
> +  _activateRecordButtons: function (shouldActivate) {

Ditto. Activate and then you ask me "shouldActivate". wut.

::: browser/devtools/performance/test/head.js
@@ +345,5 @@
>  
>    click(win, button);
>    yield clicked;
>  
> +  yield willStart;

Maybe make these checks before and after just to be sure.

Comment 4

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: 1169146-recordingbutton-clear.patch

Fixed the parameter names. Can't add a after click button-state check, there's no guarantee there what state it'll be between click and the will start/stop events (events should resolve sync, but the click yield will be async and will almost always be the same state as after the will start/stop event, but can't guarantee that)

Comment 5

[Jordan Santell [:jsantell] [@jsantell]]

 https://hg.mozilla.org/integration/fx-team/rev/65d973f2bbdf

Comment 6

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/65d973f2bbdf

Comment 7

[Nazir Ahmed Sabbir [:NaSb]]

I found this issue in Nightly 41.0a1 (2015-05-27) (Build ID: 20150527030204) on Linux x64

This Bug is now Verified as fixed on Latest Firefox Beta 41.0b3

Build ID : 20150820142145
User Agent : Mozilla/5.0 (X11; Linux x86_64; rv:41.0) Gecko/20100101 Firefox/41.0

Comment 8

[Forhad Hossain]

I have reproduced this bug in Nightly 41.0a1 (2015-05-27)(Build ID: 20150527030204) with Comment 0's instruction on Windows 10 64bit.

Bug is fixed now on latest Beta 41.0b3 (Build ID:20150820142145)

Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:41.0) Gecko/20100101 Firefox/41.0

[testday-20150821]

Comment 9

[Nazir Ahmed Sabbir [:NaSb]]

As it is verified on Linux and Windows (Comment 7 and Comment 8), Marking it as verified!