1521934 - Set devtools.responsive.metaViewport.enabled pref to true

Status: RESOLVED FIXED

(DevTools :: Responsive Design Mode, enhancement, P2)

Description

[Brad Werth [:bradwerth]]

When RDM handling of meta viewport is more stable, we should flip this pref to true. A setting of true allows meta viewport handling to be turned on and off via the docShell, which is how Responsive Design Mode works.

Comment 1

[Brad Werth [:bradwerth]]

The updated pref now controls whether or not RDM attempts a meta viewport override. Setting it to true will restore that behavior (as initially implemented without a pref in Bug 1290420).

Comment 2

[BugBot [:suhaib / :marco]]

Changing the priority to p2 as the bug is tracked by a release manager for the current nightly.
See What Do You Triage for more information

Comment 3

[Patrick Brosset <:pbro>]

[Tracking Requested - why for this release]: We are slipping to 72 and therefore do not require to track 71 anymore.

Comment 4

[Patrick Brosset <:pbro>]

Attachment: Bug 1521934 - Set devtools.responsive.metaViewport.enabled pref to true; r?bradwerth!

Now that all of the important metaViewport simulation bugs have been fixed, we would
like to let feature ride the trains, enabled by default.

This means we can also stop setting the pref in tests that rely on it.

Comment 5

[Brad Werth [:bradwerth]]

Michael, we have a gradual rollout of this pref flip tracked in Bug 1580419. When you and I discussed that, you suggested that the Experimenter-managed pref flip would start on or near the FF 72 rollout date of January 7th. Is it useful and correct for us to turn the pref on in Nightly now? Perhaps as a nightly-only pref?

Comment 6

[Michael Cooper [:mythmon]]

Sorry, I guess I wasn't clear when we talked. I would recommend making the change in Nightly on or after January 7th. The goal is that in 72 we change the preference via Normandy, and that a later Firefox version will have that preference change as the built in value. The exact timing isn't important. What's important is that if we do a rollout in 72, then one of the next few major versions has the same change. The normal pattern is that when the rollout begins in 72, we would change the pref in Nightky 74 so that it can ride the trains as well. It would also be fine to do that in Nightly 73.

Comment 7

[Patrick Brosset <:pbro>]

Thanks Michael. I've got one question though: if we enabled the pref in nightly 74 and let it ride the trains, does that mean that rollout will continue being effective all throughout 72 and 73, and then would just get disabled as the "real pref" reaches release with 74?

Additionally: we would like to use nightly and beta/devedition to test the feature. Which is why I wanted to enable the pref right now. The feedback we'll get from users on nightly and devedition is going to be important for us to understand how the feature performs, even before we do a gradual rollout in release.

Do you recommend turning it on only in pre-release channels then?

Comment 8

[Michael Cooper [:mythmon]]

if we enabled the pref in nightly 74 and let it ride the trains, does that mean that rollout will continue being effective all throughout 72 and 73, and then would just get disabled as the "real pref" reaches release with 74?

The rollout will be active for all those versions. When a user upgrades to 74 the rollout is said to "graduate", as it becomes built-in. It's different than disabling the rollout.

Additionally: we would like to use nightly and beta/devedition to test the feature. Which is why I wanted to enable the pref right now. The feedback we'll get from users on nightly and devedition is going to be important for us to understand how the feature performs, even before we do a gradual rollout in release.

Do you recommend turning it on only in pre-release channels then?

In that case, there is no problem updating the pref in prerelease versions early. Go for it.

Comment 9

[Patrick Brosset <:pbro>]

Thanks Michael! I have updated https://phabricator.services.mozilla.com/D53005 according to this.
Brad, please take a look and let me know if it works for you. We need to land this in 72 before the freeze (or very early within it).

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/1f45ebce0c2d
Set devtools.responsive.metaViewport.enabled pref to true; r=bradwerth

Comment 11

[Alexandru Michis [:malexandru]]

Backed out changeset 1f45ebce0c2d (Bug 1521934) for causing devtools failures in responsive/test/browser

Backout link: https://hg.mozilla.org/integration/autoland/rev/bb3adec7e2e28ef49f1affa26affe96095108d8f

Push with failures: https://treeherder.mozilla.org/#/jobs?repo=autoland&collapsedPushes=598800&searchStr=devtools&fromchange=74d6833f6173c10417ffc1c7baa687fd907d15ad&tochange=b4755981c1382cb88fed4e4fcff3ba73779b2080&selectedJob=277974103&group_state=expanded

Failure logs:

• https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=277974103&repo=autoland&lineNumber=17964
• https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=277981647&repo=autoland&lineNumber=21035
• https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=277996385&repo=autoland&lineNumber=6620

Comment 12

[Brad Werth [:bradwerth]]

I'll add a part to the bug to try to resolve these failures.

Comment 13

[Patrick Brosset <:pbro>]

I have some tests failing locally too, but not the ones from the failure logs above ... I have to look into it more closely.

Comment 14

[Brad Werth [:bradwerth]]

Attachment: Bug 1521934 Part 2: Update a test to specify a meta viewport size to ensure scrolling is still possible.

Comment 15

[Brad Werth [:bradwerth]]

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

Comment 16

[Julian Descottes [:jdescottes]]

Attachment: Bug 1521934 - Part 3: wait for device-changed when editing RDM device in tests

Depends on D54630

Comment 17

[Julian Descottes [:jdescottes]]

I think the only permafails were browser_device_custom_edit.js and browser_scroll.js ?
The patch in part2 fixes browser_scroll.js, the patch in part3 fixes browser_device_custom_edit.js

browser_device_width.js and browser_preloaded_newtab.js seem to be existing intermittents, and I don't think they spiked during the window where the initial patch landed ? (see the window at https://treeherder.mozilla.org/#/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel%2Crunning%2Cpending%2Crunnable&tochange=b4755981c1382cb88fed4e4fcff3ba73779b2080&searchStr=dt&fromchange=1f45ebce0c2dfa164ed6a8373e3bdb7f9b008fb8&selectedJob=277996178)

Consequently I don't know if we need to block this on Bug 1599281, IMO we could attempt to reland this.
Linux debug try with retriggers: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ab2005860673b9bf7f0178a17d0c9ce00f0ff41c
Devtools preset try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=41bc7b30fdb921956feee4d2bb6845419555e0e5

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ebc6e61b2cde
Set devtools.responsive.metaViewport.enabled pref to true; r=bradwerth
https://hg.mozilla.org/integration/autoland/rev/8545df748c79
Part 2: Update a test to specify a meta viewport size to ensure scrolling is still possible. r=pbro
https://hg.mozilla.org/integration/autoland/rev/8ec262f5d183
Part 3: wait for device-changed when editing RDM device in tests r=pbro

Comment 19

[Andrei Ciure[:aciure]]

https://hg.mozilla.org/mozilla-central/rev/ebc6e61b2cde
https://hg.mozilla.org/mozilla-central/rev/8545df748c79
https://hg.mozilla.org/mozilla-central/rev/8ec262f5d183