963852 - [B2G][Tuenti]Tuenti app does not display scroll bars.

Status: RESOLVED WONTFIX

(Tech Evangelism Graveyard :: Preinstalled B2G Apps, defect, P2)

Description

[Ross Kuhlman ([e-mail])]

Attachment: TuentiPageScrolling.txt

Tuenti is a social networking app. Many of the pages on the site can be scrolled up/down. None of the pages display scroll bars. Some pages (such as the EULA) are very lengthy to scroll through.

Repro Steps:
1) Updated Buri to BuildID: 20140122004001
2) Launch Tuenti app.
3) Navigate to a page that can be scrolled up/down. (ex: EULA, Help, Options)

Actual:
No scroll bar is displayed when user scrolls around website.

Expected:
A scroll bar is visible while user is scrolling. User can gauge where on the page they are located.

Environmental Variables:
Device: Buri v1.3 Moz RIL
BuildID: 20140121004137
Gaia: 47049555282a9a01fb60d1e1421b57e2810c96f5
Gecko: 6f7dfe36ab6c
Version: 28.0a2
Firmware Version: v1.2-device.cfg

Notes:

Repro frequency: 100%
See attached: logcat

Comment 1

[Ross Kuhlman ([e-mail])]

Issue does not occur in v1.2
Environmental Variables:
Device: Buri v1.2 Moz RIL
BuildID: 20131021004006
Gaia: 1fd315337d8ae891c3024e4c682c4c50797ea40e
Gecko: d585fe28cd55
Version: 26.0a2
Firmware Version: v1.2-device.cfg

Comment 2

[Jason Smith [:jsmith]]

This implies a gecko regression. Scrollbars should always be present when scrolling web content.

Comment 3

[Kartikaya Gupta (email:[e-mail])]

I can reproduce this on a Hamachi running latest 1.3 code, using the "create account" screen in the Tuenti app. Even with APZ turned off the scrollbar behaves strangely, flickering on and off. I added some printfs and it appears that a bunch of the time (and all the time with APZ enabled) the layer for the scrollbar doesn't get created, because the nsDisplayOwnLayer item for the scrollbars get removed from the display list.

Comment 4

[Sarah Parsons]

This issue started to occur on the first working Buri 1.3 Build ID: 20130919040201

Gaia   0dedb5b3789afc638a0c7c67652937fcb30e77d2
SourceStamp 803189f35921
BuildID 20130919040201
Version 27.0a1

Comment 5

[Timothy Nikkel (:tnikkel)]

So last 1.2 build does not have the bug, first 1.3 build does have the bug? How do we convert that to a list of changesets?

Comment 6

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #5)
> So last 1.2 build does not have the bug, first 1.3 build does have the bug?
> How do we convert that to a list of changesets?

That usually implies that this was fixed by a changeset that landed on 1.2, but the changeset that landed on 1.3 didn't fix the issue.

Comment 7

[Timothy Nikkel (:tnikkel)]

(In reply to Jason Smith [:jsmith] from comment #6)
> That usually implies that this was fixed by a changeset that landed on 1.2,
> but the changeset that landed on 1.3 didn't fix the issue.

Okay, then can we find the changeset that fixed this on 1.2 then?

Comment 8

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> > That usually implies that this was fixed by a changeset that landed on 1.2,
> > but the changeset that landed on 1.3 didn't fix the issue.
> 
> Okay, then can we find the changeset that fixed this on 1.2 then?

We could figure out the day was fixed, but I don't we get this down to the changeset.

Regression window wanted - can we find out when this last failed on 1.2, first passed on 1.2?

Comment 9

[Peter Bylenga [:PBylenga]]

the 1.2 regression window is 11-25-2013 to 11-26-2013 for when it first passed.

Last build that issue reproduced on for 1.2:
v1.2 Environmental Variables:
Device: buri v1.2 MOZ
BuildID: 20131125004001
Gaia: c2dea53b36bb9d4331a94976344515f60dc5a3d4
Gecko: 368ea26d2136
Version: 26.0
Firmware Version: v1.2-device.cfg

First build that passed for 1.2:
v1.2 Environmental Variables:
Device: buri v1.2 MOZ
BuildID: 20131125004001
Gaia: c2dea53b36bb9d4331a94976344515f60dc5a3d4
Gecko: 368ea26d2136
Version: 26.0
Firmware Version: v1.2-device.cfg

Comment 10

[Timothy Nikkel (:tnikkel)]

Looks like you accidentally pasted the 11-25 build info twice, and not the 11-26 info.

Comment 11

[Peter Bylenga [:PBylenga]]

Oops sorry about that:

First build for v1.2 that issue did not reproduce on:
v1.2 Environmental Variables:
Device: buri v1.2 MOZ
BuildID: 20131126004001
Gaia: 264c6044b941437ac3c4b28fe4ca392d2bc78445
Gecko: 21e2ad082d85
Version: 26.0
Firmware Version: v1.2-device.cfg

Comment 12

[Timothy Nikkel (:tnikkel)]

That gives
http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/pushloghtml?fromchange=368ea26d2136&tochange=21e2ad082d85
which leads me to believe
http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/28953b2f02ba
is what fixed this on 1.2. That changeset had one functional change
  +pref("ui.useOverlayScrollbars", 1);
I just checked and we have that line on the mozilla-b2g28_v1_3 repos.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #12)
> That gives
> http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/
> pushloghtml?fromchange=368ea26d2136&tochange=21e2ad082d85
> which leads me to believe
> http://hg.mozilla.org/releases/mozilla-b2g26_v1_2/rev/28953b2f02ba
> is what fixed this on 1.2. That changeset had one functional change
>   +pref("ui.useOverlayScrollbars", 1);
> I just checked and we have that line on the mozilla-b2g28_v1_3 repos.

Here's a reference to the commit with that patch btw - http://hg.mozilla.org/releases/mozilla-aurora/rev/20d8b156a140

Comment 14

[Kartikaya Gupta (email:[e-mail])]

So if that code exists on 1.3 already, there must be something else that changed between the last build of 1.2 and the first build of 1.3 that affected this. I can do a diff of the two codebases to see if anything stands out, but I need to know the gecko revision associated with the first 1.3 build. (this info isn't in comment 4).

Comment 15

[Milan Sreckovic [:milan] (needinfo for best results)]

Kats, let's keep following up on this.  Vivien, I've CC-d you because of all things scrollbar.

Comment 16

[Peter Bylenga [:PBylenga]]

9-19-2013 v1.2 Aurora
Gecko Revision: f98470e4c52dbcd3ee0236d7566df733b89f9fa9

Environment details:
Gaia   c932c482c6944fa32724ce7af9e5423c4c2bcccd
SourceStamp 2e560c5ce351
BuildID 20130919004001
Version 26.0a2

9-19-2013 v1.3 Master
Gecko Revision: 4b896261ba014196e1eb0597348939a80fe34be4

Environment details:
Gaia   0dedb5b3789afc638a0c7c67652937fcb30e77d2
SourceStamp 803189f35921
BuildID 20130919040201
Version 27.0a1

Comment 17

[Kartikaya Gupta (email:[e-mail])]

Nothing jumps out in the diff. I can try to repro what I said in comment 3 and get displaylist dumps that might shed some light on what's going on.

Comment 18

[Timothy Nikkel (:tnikkel)]

What changesets were in the diff?

Comment 19

[Kartikaya Gupta (email:[e-mail])]

I don't know. Getting a pushlog across branches is not something I've done. I just did a diff -r <rev1> -r <rev2> and grepped through the actual code diff to see if there was anything interesting.

Comment 20

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

mozilla-aurora/mozilla $ hg log -r 'ancestor(2e560c5ce351, 803189f35921)'
changeset:   155356:2520866d5874
tag:         FIREFOX_AURORA_26_BASE
user:        Ehsan Akhgari <[e-mail]>
date:        Tue Sep 17 07:42:40 2013 -0400
summary:     Backed out 2 debugging changesets (bug 916757) to avoid uplifting, now the failures have been identified; CLOSED TREE

mozilla-aurora/mozilla $ hg log -r '2520866d5874::2e560c5ce351' | less
mozilla-aurora/mozilla $ hg log -r '2520866d5874::803189f35921' | less

Comment 21

[Kartikaya Gupta (email:[e-mail])]

Attachment: Tuenti account creation displaylist (APZC enabled)

I opened the Tuenti app with APZ enabled, clicked on the "create account" link, wait for that to load, and then started logging. I flung to the bottom of the page and recorded all the paints that happened; here is the displaylist output. I will attach the non-APZ version as well, same steps were used to get it.

Comment 22

[Kartikaya Gupta (email:[e-mail])]

Attachment: Tuenti account creation displaylist (APZC disabled)

In this version we can see the OwnLayer instances that aren't in the APZ-enabled version. They show up in the first two paints but then disappear.

Comment 23

[Timothy Nikkel (:tnikkel)]

Looking at those logs my best guess is that we are dealing at the root scroll frame of a displayroot doc (toplevel document in a process). There are no scroll layer (info) display items in those dumps, which I would expect if we were looking some other scroll frame.

If a displayport is set on a display root document, then when we call ScrollFrameHelper::BuildDisplayList for the root scroll frame of it we will exit early here http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp#2313 which means we never add the scroll bars items in the AppendScrollPartsTo calls below. So if my assumptions are correct then this is what I would expect to happen, and I don't think it's changed recently. AZPC (or something else) must have been drawing the scroll bars in this case?

Comment 24

[Jean Gong :jgong]

PM triaged this bug.  This remains a blocker.

Comment 25

[Kai-Chih Hu [:khu]]

Can we get ETA to fix this bug? Thank you.

Comment 26

[Kartikaya Gupta (email:[e-mail])]

From some debugging logs it appears that :tn is correct in comment 23. If I add a call to AppendScrollPartsTo inside that early-exit condition I get scrollbars (although they're not layerized separately and so don't get scrolled async the way I want). CC'ing :mstange also because he touched this code recently and :tn is probably swamped with things so maybe he can help me out here.

Incidentally, as :tn surmised, this means that any display root document with a displayport will not get scrollbars. This includes browser content. Raise your hand if you noticed that there are no scrollbars for browser content on 1.3. That was probably the case in 1.2 as well, since APZ was enabled for browser content there. It would be nice to get verification on that. I don't have a 1.2 build available to test.

Comment 27

[Timothy Nikkel (:tnikkel)]

So there's never been a case where we hit the early exit in ScrollFrameHelper::BuildDisplayList _and_ drew scrollbars? So AppendScrollPartsTo is the only thing that does it?

Comment 28

[Kartikaya Gupta (email:[e-mail])]

As far as I can tell, yes. On Fennec we draw scrollbars in Java-land so that doesn't count. In fact if we fix this here we might end up with double scrollbars in Fennec. Not sure about that.

Comment 29

[Kartikaya Gupta (email:[e-mail])]

I tried a few things that I thought made sense but apparently they didn't because they caused all sorts of nasty regressions. At this point I'm not sure of:

(a) if we should be calling AppendScrollPartsTo unconditionally in the early-exit branch at [1]; if not, where and under what conditions should it be called? The comment in that branch implies that not drawing scrollbars there is desired.

(b) Why the scrollbars don't get their own layers when I call AppendScrollPartsTo with aCreateLayer=true there. It looks like the scrollbars get flattened into the content, and I'm not sure why. It's quite possible that just calling AppendScrollPartsTo there will build the displaylist wrongly (I see an OwnLayer end up at the root of the displaylist list tree output, which seems wrong) but I'm not sure what to do to make it right.

NI'ing :mstange for help here, but :tn also please feel free to advise if you're not busy on other 1.3 blockers and any ideas come to mind.

[1] http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsGfxScrollFrame.cpp?rev=02f906d9f8f6#2307

Comment 30

[Markus Stange [:mstange]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #29)
> I tried a few things that I thought made sense but apparently they didn't
> because they caused all sorts of nasty regressions. At this point I'm not
> sure of:
> 
> (a) if we should be calling AppendScrollPartsTo unconditionally in the
> early-exit branch at [1]; if not, where and under what conditions should it
> be called? The comment in that branch implies that not drawing scrollbars
> there is desired.

I don't know the answer. I don't understand the reasoning of that if block, I'll have to spend more time making myself familiar with the problem it solves.

> (b) Why the scrollbars don't get their own layers when I call
> AppendScrollPartsTo with aCreateLayer=true there. It looks like the
> scrollbars get flattened into the content, and I'm not sure why. It's quite
> possible that just calling AppendScrollPartsTo there will build the
> displaylist wrongly (I see an OwnLayer end up at the root of the displaylist
> list tree output, which seems wrong) but I'm not sure what to do to make it
> right.

I can try to debug this later today.

Comment 31

[Kartikaya Gupta (email:[e-mail])]

Attachment: WIP

So after some experimenting this seems to have the desired effect. The end layer structure here is:

- ContainerLayer (root, no frame metrics)
  - ContainerLayer (contains the scrollable content, has frame metrics)
    - ThebesLayer with content
  - ContainerLayer (for scrollbar, has vscrollbar flag set)
    - ThebesLayer to draw the scrollbar

The problem I was seeing with some of my earlier experiments was that the root ContainerLayer and the content ContainerLayer both ended up with the same scrollId so they both got async transforms in the compositor. Commenting out the RFM call for the root container layer fixes that.

Comment 32

[Kartikaya Gupta (email:[e-mail])]

I'll look to see if applying some/all of the patches from bug 959847 puts us in a better position to implement this.

Comment 33

[Kartikaya Gupta (email:[e-mail])]

Unfortunately those patches don't make much difference. I still have to comment out the call to RFM in nsDisplayList::PaintForFrame for it to work properly.

Comment 34

[Timothy Nikkel (:tnikkel)]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #32)
> I'll look to see if applying some/all of the patches from bug 959847 puts us
> in a better position to implement this.

Those patches shouldn't have much of an effect on b2g, on Fennec and metro they will go in the opposite direction of what you want (they remove a container layer).

Comment 35

[Timothy Nikkel (:tnikkel)]

Sounds like it was the RFM call on the root layer that was confusing apzc. Commenting out http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMWindowUtils.cpp#396 and removing the RFM for the root layer should have the same effect.

Comment 36

[Kartikaya Gupta (email:[e-mail])]

I was discussing this Timothy a bit and we were wondering if the scrollbars were ever present in browser content. qawanted to check on 1.1 and 1.2 - please just load a simple page like https://people.mozilla.org/~kgupta/grid.html in the browser and check if there are scrollbars. If there are no scrollbars then I'm not sure this bug should block 1.3 as we're only being consistent in behaviour between the browser and apps. If there are scrollbars then getting a regression range on when they disappeared would be helpful.

Comment 37

[Peter Bylenga [:PBylenga]]

v1.1 there are no scrollbars when scrolling on the page listed in Comment 36

v1.1 Environmental Variables:
Device: Buri v1.1 MOZ
BuildID: 20140206041207
Gaia: c5cb252e5d1aa45d14f3a2ea182e73e2271e4496
Gecko: adaf8883268e
Version: 18.0
Firmware Version: v1.2-device.cfg

v1.2 there are no scrollbars when scrolling on the page listed in Comment 36

Buri v1.2 Moz RIL
Gaia   539a25e1887b902b8b25038c547048e691bd97f6
Gecko 1592ce49929c
BuildID 20140207004002
Version 26.0

Comment 38

[Jason Smith [:jsmith]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #36)
> I was discussing this Timothy a bit and we were wondering if the scrollbars
> were ever present in browser content. qawanted to check on 1.1 and 1.2 -
> please just load a simple page like
> https://people.mozilla.org/~kgupta/grid.html in the browser and check if
> there are scrollbars. If there are no scrollbars then I'm not sure this bug
> should block 1.3 as we're only being consistent in behaviour between the
> browser and apps. If there are scrollbars then getting a regression range on
> when they disappeared would be helpful.

That's technically different than the issue present here - the bug here showcases this was working previously with the same packaged app in question, as the regression range shows this is working on 1.2 right now, but has become broken on 1.3. This is blocker for a content partner, so we need a resolution in gecko here.

Comment 39

[Kartikaya Gupta (email:[e-mail])]

(In reply to Jason Smith [:jsmith] from comment #38)
> That's technically different than the issue present here - the bug here
> showcases this was working previously with the same packaged app in
> question, as the regression range shows this is working on 1.2 right now,
> but has become broken on 1.3. This is blocker for a content partner, so we
> need a resolution in gecko here.

It's technically different... but not really. Aren't apps supposed to be just like websites? Getting rid of the browser as will happen in future releases just reinforces this. What's actually happening here is that we're being *more* consistent with respect to showing scrollbars - now we treat apps and browser content the same. Obviously nobody cared that the browser was missing scrollbars for three releases so I don't see why it's such a big deal that apps behave the same way. In my mind this falls under the "feature, not a bug" category, same as how Gaia apps should now be required to have meta-viewport tags.

Comment 40

[Timothy Nikkel (:tnikkel)]

So if pref("ui.useOverlayScrollbars", 1); fixed this on 1.2, then what effect does flipping that pref have on 1.3 builds? Adding qawanted to find out if setting the pref ui.useOverlayScrollbars to 1 ever fixed this bug, and if so when did that change. 2013-11-23 and onward should have this pref already set to 1.

Comment 41

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #40)
> So if pref("ui.useOverlayScrollbars", 1); fixed this on 1.2, then what
> effect does flipping that pref have on 1.3 builds? Adding qawanted to find
> out if setting the pref ui.useOverlayScrollbars to 1 ever fixed this bug,
> and if so when did that change. 2013-11-23 and onward should have this pref
> already set to 1.

It's already preffed on - http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/44838b3b9bf7/b2g/app/b2g.js#l609.

So are you asking that we check what happens if it's set to zero? Because it looks like we're already testing a build with it preffed on.

Comment 42

[Jason Smith [:jsmith]]

(In reply to Kartikaya Gupta (email:[e-mail]) from comment #39)
> (In reply to Jason Smith [:jsmith] from comment #38)
> > That's technically different than the issue present here - the bug here
> > showcases this was working previously with the same packaged app in
> > question, as the regression range shows this is working on 1.2 right now,
> > but has become broken on 1.3. This is blocker for a content partner, so we
> > need a resolution in gecko here.
> 
> It's technically different... but not really. Aren't apps supposed to be
> just like websites? Getting rid of the browser as will happen in future
> releases just reinforces this. What's actually happening here is that we're
> being *more* consistent with respect to showing scrollbars - now we treat
> apps and browser content the same. Obviously nobody cared that the browser
> was missing scrollbars for three releases so I don't see why it's such a big
> deal that apps behave the same way. In my mind this falls under the
> "feature, not a bug" category, same as how Gaia apps should now be required
> to have meta-viewport tags.

We are supposed to move to a model where apps & websites are viewed interchangeably in a similar manner. Sounds like the changed behavior on 1.3 I think might be due to enabling of APZC across apps, which makes me think that the regression range on 1.3 is incorrect. For the QA Wanted request - can someone check if disabling APZC fixes this bug?

If this is an expected fallout from turning APZC on in apps, then we do have the option to outreach to the partner here via TE to fix this. We do need to be careful here though, as our existing strategy for apps with APZC was to ensure that we had a hack in place to ensure that there were no user visible regressions with APZC on with apps (i.e. the hack Vivien implemented for the default meta viewport). If we take the TE route, then we need to explain this in dev docs & to content partners when to expect scrollbars to no longer show up. I think that might be okay here though, given that this problem isn't happening on every partner app we've tested so far (we've only seen it with Tuenti), so the TE approach might be easier to do than introducing a hack.

Comment 43

[Jason Smith [:jsmith]]

Well, the plan above failed. APZC turned off still reproduces the bug.

Comment 44

[Timothy Nikkel (:tnikkel)]

(In reply to Jason Smith [:jsmith] from comment #41)
> (In reply to Timothy Nikkel (:tn) from comment #40)
> > So if pref("ui.useOverlayScrollbars", 1); fixed this on 1.2, then what
> > effect does flipping that pref have on 1.3 builds? Adding qawanted to find
> > out if setting the pref ui.useOverlayScrollbars to 1 ever fixed this bug,
> > and if so when did that change. 2013-11-23 and onward should have this pref
> > already set to 1.
> 
> It's already preffed on -
> http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/44838b3b9bf7/b2g/app/
> b2g.js#l609.
> 
> So are you asking that we check what happens if it's set to zero? Because it
> looks like we're already testing a build with it preffed on.

The pref got set to 1 in late November. So I'm asking to look at builds before late november and force set the pref to 1.

Comment 45

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #44)
> (In reply to Jason Smith [:jsmith] from comment #41)
> > (In reply to Timothy Nikkel (:tn) from comment #40)
> > > So if pref("ui.useOverlayScrollbars", 1); fixed this on 1.2, then what
> > > effect does flipping that pref have on 1.3 builds? Adding qawanted to find
> > > out if setting the pref ui.useOverlayScrollbars to 1 ever fixed this bug,
> > > and if so when did that change. 2013-11-23 and onward should have this pref
> > > already set to 1.
> > 
> > It's already preffed on -
> > http://hg.mozilla.org/releases/mozilla-b2g28_v1_3/file/44838b3b9bf7/b2g/app/
> > b2g.js#l609.
> > 
> > So are you asking that we check what happens if it's set to zero? Because it
> > looks like we're already testing a build with it preffed on.
> 
> The pref got set to 1 in late November. So I'm asking to look at builds
> before late november and force set the pref to 1.

Okay - so we're doing a regression range with that pref set on builds before late November. Got it.

Comment 46

[Timothy Nikkel (:tnikkel)]

(In reply to Jason Smith [:jsmith] from comment #43)
> Well, the plan above failed. APZC turned off still reproduces the bug.

I disabled apzc for apps, still didn't see scrollbars in tuenti, then I rebooted, checked that it was still disabled, and then I saw scrollbars in tuenti.

Comment 47

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #46)
> (In reply to Jason Smith [:jsmith] from comment #43)
> > Well, the plan above failed. APZC turned off still reproduces the bug.
> 
> I disabled apzc for apps, still didn't see scrollbars in tuenti, then I
> rebooted, checked that it was still disabled, and then I saw scrollbars in
> tuenti.

Actually, that comment was for a different bug (sorry for the confusion). Okay, that confirms that enabling of APZC is causing this.

Comment 48

[Jason Smith [:jsmith]]

Now that we've got firm evidence that this is an APZC fallout, let's go forward with the TE route here. Unblocking this for 1.3 as this is now a TE bug.

Kats - Can you give a summary of what the Tuenti developer needs to do to get scrollbars working in his app with APZC enabled?

Comment 49

[Timothy Nikkel (:tnikkel)]

When was apzc enabled for apps? From the bug it looks like in december, but this regressed before that, so I'd still like that range, if enabling azpc for apps didn't regress this I'd very much like to know what did.

Comment 50

[Timothy Nikkel (:tnikkel)]

(In reply to Jason Smith [:jsmith] from comment #48)
> Kats - Can you give a summary of what the Tuenti developer needs to do to
> get scrollbars working in his app with APZC enabled?

One workaround would be to put the scrollable content in an element with overflow: scroll, instead of the body/html being the scrollable container. Or putting the scrollable content in an iframe would work too.

Comment 51

[Jason Smith [:jsmith]]

(In reply to Timothy Nikkel (:tn) from comment #49)
> When was apzc enabled for apps? From the bug it looks like in december, but
> this regressed before that, so I'd still like that range, if enabling azpc
> for apps didn't regress this I'd very much like to know what did.

We already got a range here - it pointed at the first 1.3 build. I think that's because of the fact that the tester left the APZC pref on when she was testing older builds, which is why the regression range points to the first 1.3 build. The recent testing showcases this working with APZC off, but busted when it's on, which leaves me to believe that kats's analysis above is correct that this is compat fallout from trying to align apps & web content together.

We don't to continue QA investigation here - this is a TE problem at this point. This is a problem for the content team to handle.

Comment 52

[Kartikaya Gupta (email:[e-mail])]

(In reply to Jason Smith [:jsmith] from comment #48)
> Kats - Can you give a summary of what the Tuenti developer needs to do to
> get scrollbars working in his app with APZC enabled?

Basically what Timothy said in comment 50. That being said, I think the app is fine the way it is, without scrollbars. This is consistent with how content is viewed in the browser. It's up to the app developer to choose what they want here.

Comment 53

[Sylvestre Ledru [:Sylvestre]]

Mass closing on Tech Evangelism::Preinstalled B2G App as Firefox OS is no longer a thing.

Comment 54

[Sylvestre Ledru [:Sylvestre]]

Mass closing on Tech Evangelism::Preinstalled B2G App as Firefox OS is no longer a thing.

Comment 55

[Sylvestre Ledru [:Sylvestre]]

Mass closing on Tech Evangelism::Preinstalled B2G App as Firefox OS is no longer a thing.