Closed Bug 1521934 Opened 11 months ago Closed 6 days ago

Set devtools.responsive.metaViewport.enabled pref to true

Categories

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

enhancement

Tracking

(firefox72+ fixed)

RESOLVED FIXED
Firefox 72
Tracking Status
firefox72 + fixed

People

(Reporter: bradwerth, Assigned: bradwerth)

References

(Depends on 2 open bugs, Blocks 1 open bug)

Details

Attachments

(3 files)

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.

Blocks: rdm-ux
Depends on: 1501665
Depends on: rdm-meta-viewport
No longer depends on: 1501665

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).

Summary: Set dom.meta-viewport.enabled pref to true on desktop → Set devtools.responsive.metaViewport.enabled pref to true
Priority: -- → P3
Assignee: nobody → bwerth

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

Priority: P3 → P2

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

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.

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?

Flags: needinfo?(mcooper)
See Also: → 1580419

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.

Flags: needinfo?(mcooper)

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?

Flags: needinfo?(mcooper)

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.

Flags: needinfo?(mcooper)

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).

Pushed by pbrosset@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/1f45ebce0c2d
Set devtools.responsive.metaViewport.enabled pref to true; r=bradwerth

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

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

Depends on: 1599281

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

Pushed by pbrosset@mozilla.com:
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
Flags: needinfo?(pbrosset)
You need to log in before you can comment on or make changes to this bug.