Open Bug 1213951 Opened 9 years ago Updated 7 months ago

Add "fit" option to ensure entire viewport is visible

Categories

(DevTools :: Responsive Design Mode, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: jryans, Unassigned)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [rdm-v2])

Attachments

(1 file)

We should offer some kind of "fit" option to force the viewport to scale so the entire viewport is visible no matter the size of the browser window.  This would not change the document size inside the viewport, but instead scales down the viewport if needed to keep it all on screen at once.

Chrome's device mode offers this feature currently.
Whiteboard: [devtools-ux]
We have discussed a "fit" option several times as a team, but it's never been triaged so far, so let's discuss it.

It sounds like a helpful ability, especially with multiple viewports, but even for a single viewport that you want to set to a size larger than the browser window in one or both dimensions.
Whiteboard: [devtools-ux] → [devtools-ux][multiviewport][triage]
Flags: qe-verify?
Priority: -- → P4
Whiteboard: [devtools-ux][multiviewport][triage] → [devtools-ux][multiviewport]
Priority: P4 → P3
Whiteboard: [devtools-ux][multiviewport] → [multiviewport] [reserve-rdm]
Priority: P3 → P2
Flags: qe-verify? → qe-verify+
QA Contact: mihai.boldan
Priority: P2 → P3
Priority: P3 → P2
Priority: P2 → P1
Priority: P1 → P3
Whiteboard: [multiviewport] [reserve-rdm] → [rdm-v2]
(In reply to Lyubomir Parvanov from comment #3)
> Does it really take 1 year for such a change? In my whole life i thought
> that open-source products are faster in development than other "proprietary"
> ones. :(
Yes it can take years if no one works on the issue. Simply asking for it to be implemented doesn't make it so. Sharing your experience, use cases, or even offer your help to test, or implement the feature is what would have a much more positive effect on this bug.
Myself, I'd also really love this bug to be fixed, but so far, we've not been able to prioritize that over other things the Mozilla DevTools team has been working on lately.
If there is progress, it should happen here in this bug.  Continually asking if there is progress is not helpful and violates Bugzilla etiquette guidelines[1].

[1]: https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Product: Firefox → DevTools

I realise this doesn't add anything new to the issue as such, but I was using a laptop to develop a website and had to abandon using Firefox Developer Edition due to a lack of this feature. Developing on a laptop and previewing for larger screens just isn't feasible because navigating the site, and seeing elements in their intended emphasis and proximity within the viewport isn't possible.

If there's anything else I can add to help, or in any way escalate this issue then happy to do so.

Depends on: rdm-ux
Blocks: rdm-zoom
No longer depends on: rdm-ux
See Also: → 1491876

As a frontend developer the use cases for this are almost infinite, this is one of the most used features i have in chromium (can't say i really realized that until i didn't have it):

  • testing different screen resolutions, especially ones larger than my laptop screen. Or realistically, almost ANY screen.. since i also have devtools open next to any device I'm emulating.. making my max testable resolution about 1300x
  • comparing multiple screen sizes/ layouts side by side (i realize there are extensions / services for this as well)
  • investigating layouts, such as grid and flexbox placements, while still maintaining the ability to click on elements within the viewport to inspect them (now about half of them could be hidden by the devtools window)
  • resizing various resolutions to observe layout changes at breakpoints. this is tedious and / or impossible with the current device emulation arrangement.. I end up just dragging an edge of the device behind the devtools window and not being able to really observe much of anything.

In addition to making things smaller, it is also nice to be able to zoom in order to inspect strange small web page artifacts that are otherwise hard to see / unclickable.

  • Testing tablet resolutions that are in portrait orientation, these often have a greater vertical dimension that most desktop screens ( > 1000px effective pixels, they are dual DPI). factor in a toolbar across the top of FF, a menu bar in my OS and there is no way to view any tablet resolutions completely in portrait mode on a 1920 x 1080 screen.

The Chrome DevTools actually have two different but related options to fit the viewport into the visible area. One is called "Fit to window" which is a one-off option to adjust the zoom of the viewport manually to fit into the visible area. And the other one is called "Auto-adjust zoom" which adjusts the zoom whenever the "Dimensions" option is changed.
Also, the zoom within their responsive design mode seems to be independent of the actual page zoom.

The question is whether to match this and provide the same functionality or do it differently. I would say that in a first step the RDM zoom should be made independent of the page zoom. In a second step a fit-to-visible-area feature as discussed here should be added. And I could imagine to have only one "Auto-adjust zoom" option that always automatically adjusts the zoom of the RDM viewport to fit into the visible area, i.e. also when the browser window is resized.

In addition to that, the Chrome DevTools resize the viewport automatically to fit into the visible area when "Responsive" is chosen from the Dimensions drop down. This might also be covered by this change to change the zoom level. Or it could be implemented as in Chrome by changing the viewport size instead of its zoom level.

Sebastian

Severity: normal → S3

Agree that making RDM zoom independent of regular page zoom a first step. You can zoom in/out using Ctrl/Cmd-+/- keys, but the RDM window is centered to the center of the viewport instead of the center of the RDM window. See screenshot to see what i mean.

You need to log in before you can comment on or make changes to this bug.