When Folha is installed as an app the content doesn't zoom out and pinch to zoom is disabled also. However, when the same content (app.folha.com) is viewed with the browser it is scaled correctly.

So this isn't a bug in the app. The zoom in/out piece is actually irrelevant here. What is relevant that this is probably a viewport bug.

(In reply to Jason Smith [:jsmith] from comment #1) > So this isn't a bug in the app. The zoom in/out piece is actually irrelevant > here. What is relevant that this is probably a viewport bug. is this something the app developers need to address or us?

(In reply to Andrew Williamson [:eviljeff] from comment #2) > (In reply to Jason Smith [:jsmith] from comment #1) > > So this isn't a bug in the app. The zoom in/out piece is actually irrelevant > > here. What is relevant that this is probably a viewport bug. > > is this something the app developers need to address or us? We need to address it, although this likely isn't getting fixed for v1 at this point, so we may dev-doc-needed on this to provide a temp mitigation.

Jonas - do you know (or do you know who might know) if this is a viewport bug?

Chris Jones may be able to help here, too.

We don't support meta viewport for "app" content. I don't want to but we have to do that in the future.

Yes, we should definitely support meta-viewport for apps the same way we do in web pages. As much as I agree that having to do so sucks, I think having a smooth and consistent transition path from websites to apps will make it easier for developers. Matt, how much work would it be to implement this? I don't think this is a blocker, but it'd be nice to fix sooner rather than later.

I've never really touched the FxOS parts of the meta viewport code, nor do I really know the various differences between apps and browser tabs on FxOS, so I really have no idea what this would involve. CCing some random people. (It's too bad cjones is no longer with us...) If apps and browser tabs use the same async panning/zooming code, then I expect it should be somewhat straightforward to get parity. Otherwise, probably quite hard. Mostly you need to call nsContentUtils::GetViewportInfo at the appropriate times and then use the results correctly to resize the viewport. From some quick searches through MXR, it looks like most of the FxOS code for this is in TabChild. Is that class used for apps as well as tabs? There is also some possibly-related code in BrowserElementPanning.js. See also discussion around bug 746502 comment 18 and https://groups.google.com/d/topic/mozilla.dev.b2g/eNThZLhBZ8o/discussion (where I argued for supporting this the start, and others argued against).

Oops, I meant to add drs and jwir3 for input.

AFAIK, right now only the browser app uses a <browser remote> element, and is thus the only app to to use the APZC code path. The async/APZC code path takes care to honor meta viewport tags, but the sync path doesn't. To explain, I'll have to elaborate on this: (In reply to Chris Jones [:cjones] [:warhammer] from comment #6) > We don't support meta viewport for "app" content. I don't want to but we > have to do that in the future. Based on my talking with cjones, I think the reason he opposed this is because he believed it was bad design to require meta viewport constraints within our apps. He thought that it was a symptom of poor layout, since we know what widgets the apps will ultimately be displayed on. I'm not sure how he wanted to prevent zooming, though. I don't share the same opinion, but he never fully explained his thought process on this to me. Either way, this will require changing the sync path to read and honor the meta viewport tag. The async code is a good reference point.

Oh, I should also add that a lot of work was done to generalize the meta viewport reading and parsing code. This should be significantly easier to do now than the async case was (bug 746502), but I don't know enough about the surrounding code to say.