Closed Bug 774055 Opened 9 years ago Closed 3 years ago

[responsive view] support the viewport meta tag

Categories

(DevTools :: Responsive Design Mode, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1290420

People

(Reporter: darktrojan, Unassigned)

References

(Blocks 4 open bugs)

Details

Attachments

(1 file)

This would be great for developing on mobile sites. The code handling it on Android is here, but I don't know how much of that would work straight away on desktop.
http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/browser.js#4429
Can you describe exactly what you mean by "supporting viewport meta tag"?

We can easily resize the page to the defined width and height by default if defined.
But we can't support device-width and device-height.

And afaik, most of the time, people use device-width.

What about the other values (like zoom)?
What I'm trying to do is test how a mobile browser displays a website without actually using a mobile browser. We should read the width, height and scale values and set the page's zoom level accordingly (actually that's much easier than I first thought), and ideally behave in the same way as Fennec does if the user changes the zoom level (not so easy).
I'm sorry, I'm still not sure to understand.

Read the width value from the viewport meta tag? Do actually use width=xxx? Or width=device-width? And by zooming, you mean taking dpi into account? If so, this is bug 758011.
Currently the responsive view resizes the CSS viewport to match the size of the <browser> element, just like a desktop browser does when you resize its window.

But this is not what mobile browsers do.  Instead, they lay out the page using a CSS viewport that might be larger or smaller than the browser window, and let you zoom and pan to view different parts of this viewport.

By default (on a page with no <meta name=viewport> element), a mobile browser will render a page at a width of 980px (for Fennec; some browsers use slightly different default widths).  Initially the page will be zoomed out to fit all 980px on-screen.

If the page has <meta name="viewport" content="width=device-width"> then the browser will resize the viewport to match the browser window, as the current responsive view does.

Pages can also set an explicit <meta name="viewport" content="width=500">, in which case the CSS viewport should always remain at that width regardless of the <browser> size.

The page can also control the viewport height and zoom level using the meta tag.

See http://quirksmode.org/mobile/viewports2.html which also discusses the effects of this "virtual" viewport on properties like window.innerWidth and screen.width.
I understand what the viewport meta tags does (see bug 752473 comment 19).

The responsive mode is not a mobile simulator.

I'd like to understand what "supporting viewport meta tag in responsive view" would mean.
Should we go into a mode where we simulate mobile rendering with a virtual viewport (faking pixels)?
If so, this is not directly related to the responsive mode view (but could be used in combination with such a mode).
(In reply to Paul Rouget [:paul] from comment #5)
> Should we go into a mode where we simulate mobile rendering with a virtual
> viewport (faking pixels)?
> If so, this is not directly related to the responsive mode view (but could
> be used in combination with such a mode).

Yes, extending the responsive view mode to (optionally) act more like a mobile simulator would be very useful, since developers who are concerned with how a site renders at different sizes are probably very interested in how it renders on different mobile devices.
This is what I think should be done:
- if no viewport meta tag: resize to 980
- if width=device-width: resize to 320
- if width=XXX: resize to XXX

This would happen when the responsive mode is started for the very first time for a specific page. If the user resize the page, the new size is considered as the future default size for this specific page.

How does that sound?
Blocks: 749628
Blocks: 778169
(In reply to Paul Rouget [:paul] from comment #7)
> This is what I think should be done:
> - if no viewport meta tag: resize to 980
> - if width=device-width: resize to 320
> - if width=XXX: resize to XXX
> 
> This would happen when the responsive mode is started for the very first
> time for a specific page. If the user resize the page, the new size is
> considered as the future default size for this specific page.
> 
> How does that sound?

By resize do you mean resize the browser element displaying the page, or resize the page to be that wide and then scale to make it fit the browser? I guess both effectively show the same thing, but I don't think users would be expecting the browser size to change without them doing something.
(In reply to Geoff Lankow (:darktrojan) from comment #8)
> (In reply to Paul Rouget [:paul] from comment #7)
> > This is what I think should be done:
> > - if no viewport meta tag: resize to 980
> > - if width=device-width: resize to 320
> > - if width=XXX: resize to XXX
> > 
> > This would happen when the responsive mode is started for the very first
> > time for a specific page. If the user resize the page, the new size is
> > considered as the future default size for this specific page.
> > 
> > How does that sound?
> 
> By resize do you mean resize the browser element displaying the page, or
> resize the page to be that wide and then scale to make it fit the browser? I
> guess both effectively show the same thing,

resize of the browser.

> but I don't think users would be
> expecting the browser size to change without them doing something.

It happens when you start the responsive mode. So they do something.
We already resize the page (current size - 40px)
Component: Developer Tools → Developer Tools: Responsive Mode
Blocks: 878559
Blocks: 878561
Attached image devtools-comparison.png
All these are 

360x640 with Firefox Android UA

from left to right
* Gecko  (Firefox) responsive mode
* WebKit (Safari)  responsive mode
* Blink  (Opera)   responsive mode
Product: Firefox → DevTools
Going to close this as a dupe of 1290420, because there are WIP patches over there.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1290420
You need to log in before you can comment on or make changes to this bug.