1663173 - New Print modal is broken inside Customize page

Status: VERIFIED FIXED

(Firefox :: Toolbars and Customization, defect, P3)

Description

[Anca Soncutean, Desktop QA]

Attachment: screenshot on customize page.png

Affected versions

• 81.0b6
• 82.0a1 (2020-09-04)

Affected platforms

• Windows 10
• macOS 10.15
• Ubuntu 18.04

Steps to reproduce

1. Launch Fx
2. Make sure print.tab_modal.enabled is set on true
3. Open customize page
4. Hit Ctrl + P

Expected result

• Print modal is broken and no interaction with the modal can be made)

Actual result

• Print modal is not broken

Regression range

• First bad: e375b85cfba38ff5f49493d1d48b7561f7f2f8d7 (2020-08-20)
• Last good: b0888d07df690ed43df31a2b013d12464b183a30 (2020-08-19)
• Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b0888d07df690ed43df31a2b013d12464b183a30&tochange=e375b85cfba38ff5f49493d1d48b7561f7f2f8d7

Suggested severity

• S3

Comment 1

[Blake Winton (:bwinton) (:☕️)]

(Might be a more general TabDialogBox bug, so tagging Gijs…)

Comment 2

[:Gijs (he/him)]

Print is supposed to be disabled in customize mode (and indeed, the menuitem is disabled, so it's curious that the shortcut works...). Other dialogs also won't / shouldn't appear in customize mode. The reason things get mispositioned is that customize mode displays instead of a "real" tab.

Comment 3

[:Gijs (he/him)]

Attachment: Bug 1663173 - disable commands that don't need to be enabled in customize mode, r?mconley

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ffe1c9f9f9df
disable commands that don't need to be enabled in customize mode, r=mconley

Comment 5

[Razvan Maries]

Backed out for perma failures.

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=Bp9-_jTkRIyLnKME0Y3cgw.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=8f7d601341b453b9ec17d45922e9988fa83a6f0f&searchStr=bc&failure_classification_id=2

Log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=315253986&repo=autoland&lineNumber=11331

Backout: https://hg.mozilla.org/integration/autoland/rev/3a2d17ccc986413be16be59e04c0e4a6fe51a638

Comment 6

[:Gijs (he/him)]

(In reply to Razvan Maries from comment #5)

Backed out for perma failures.

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&selectedTaskRun=Bp9-_jTkRIyLnKME0Y3cgw.0&resultStatus=testfailed%2Cbusted%2Cexception&revision=8f7d601341b453b9ec17d45922e9988fa83a6f0f&searchStr=bc&failure_classification_id=2

Log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=315253986&repo=autoland&lineNumber=11331

Backout: https://hg.mozilla.org/integration/autoland/rev/3a2d17ccc986413be16be59e04c0e4a6fe51a638

Bah, this is dumb. Here's why tests broke:

1. we enter customize mode. Commands get disabled
2. we construct widgets to show them in the palette. They have "command" attributes. They inherit the "disabled" command from the command in question
3. we leave customize mode. The widgets from (2) go back into the palette
4. we remove the disabled attributes from the commands. Now, first off, I'm not sure how well this propagates even to things that are in the DOM at that point (cf. bug 309953). But the commands that went back into the palette definitely don't get those attributes re-sync'd.
5. we try to use some of those widgets by adding them into the UI using API calls. They are still disabled because we missed them in step (4).

It's not super clear to me if this can happen in normal use, as users can't really manipulate the toolbar using API calls, and if items get moved into a toolbar / menu during customize mode, they won't be missed in step (4). Still, it feels like a bad pitfall to leave lying around, and it points to maybe the location where the enabling/disabling happens not being the right one, or something. So I'll look if I can improve the patch to avoid this breaking.

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/77840a2500c4
disable commands that don't need to be enabled in customize mode, r=mconley

Comment 8

[Cristina Coroiu [:ccoroiu]]

https://hg.mozilla.org/mozilla-central/rev/77840a2500c4

Comment 9

[Bogdan Maris, Desktop QA]

Reproduced the initial issue using old Nightly from (2020-09-04), verified that the issue is fixed in Firefox 82.0b2 across platforms (Windows 10 64bit, macOS 10.15 and Ubuntu 18.04).

Comment 10

[Maria Berlinger [:mberlinger], Services QA]

https://testrail.stage.mozaws.net/index.php?/cases/view/1084036