This is not easily reproducible but most of the gaia team have seen this. We definetely have seen this in Settings and Sms. :vingtetun thinks this might be a focus problem because the Camera icon is at the left top of the homescreen, and so by wanting to press the back button we're really pressing the icon. Next step is to find good STR, so marking qawanted.

Case 1: Wallpaper Settings STR: 1. go to settings 2. go to Display 3. select Wallpaper 4. select Camera 5. hit home to cancel out of taking a picture because you changed your mind Expected: go back to settings Actual: goes to homescreen Case 2: Sending Picture via email (not so much with Camera app) 1. go to gallery 2. select a photo 3. share photo 4. send via email 5. hit home before sending the email Expected: go back to gallery Actual: goes to homescreen Not sure if this is what is being sought after. Please capture a screenshot if it is not.

Sorry for not being clear at first. A screenshot won't be useful here. Here are some steps that reproduce sometimes the problem: * you are in the settings app, in some subpanel * you press '<' to access to the parent panel * instead of showing the parent panel, it launches the camera Another way: * you are in the contacts app, in a navigation page * you press '<' to access to the home panel * instead of showing the home panel, it launches the camera We think that it launches the camera because this is the icon positioned at this place on the Homescreen, and therefore that the fact that this specific app is launching is irrelevant.

I'm not sure it should be blocking basecamp because this happens quite rarely and it doesn't impact the phone's sanity.

Related? https://bugzilla.mozilla.org/show_bug.cgi?id=819200

I don't think so but I may be wrong. Rather we suspect a focus problem wrt the homescreen.

My guess is that this is related to the weird scrolling and contextmenu bustage. Open up gallery, and swipe to scroll though the list of thumbnails. Then tap on a thumbnail. If the thumbnail appears right away, then you don't have a build with the regression in it, so stop here. Otherwise you've got a build where the first tap after a scroll is broken. I hypothesize that if you scroll and then tap in the upper-left corner, that tap will be delivered to the homescreen and will launch the camera. Or if you tap in the lower right, it will launch the browser. (I've seen that happen recently, to). I've just gotten an OTA update and the regression I'm describing is no longer there, so I can't test my own hypothesis.

(In reply to Naoki Hirata :nhirata from comment #1) > Case 1: Wallpaper Settings > Expected: go back to settings > Actual: goes to homescreen > > Case 2: Sending Picture via email (not so much with Camera app) > Expected: go back to gallery > Actual: goes to homescreen > > Not sure if this is what is being sought after. Please capture a screenshot > if it is not. These are expected behavior. Home button always goes to home screen, see bug 812252. (In reply to Julien Wajsberg [:julienw] from comment #2) > Sorry for not being clear at first. A screenshot won't be useful here. > > Here are some steps that reproduce sometimes the problem: > > * you are in the settings app, in some subpanel > * you press '<' to access to the parent panel > * instead of showing the parent panel, it launches the camera > > Another way: > > * you are in the contacts app, in a navigation page > * you press '<' to access to the home panel > * instead of showing the home panel, it launches the camera > > We think that it launches the camera because this is the icon positioned at > this place on the Homescreen, and therefore that the fact that this specific > app is launching is irrelevant. I am not being able to reproduce this. Is this really a bug?

Tim, as I said, this is quite rare and difficult to reproduce and as you I don't think it should block basecamp (comment 3). However it definitely happen (I saw it yesterday again, and others too). It may have been fixed (comment 6) but I think I saw it yesterday whereas I had a build with this fix. I am not sure though.

I'm able to reproduce this as well, but I can't get it to happen consistently.

Sorry. I misunderstood the issue at the start. I can get it to reproduce consistently. It has to do with the timing of launch of settings and hitting the back 1. make sure the settings and camera app is closed using the task manager 2. launch settings 3. as soon as settings launches go into a submenu such as network 4. as soon as it switches, tap the area where the back < would be placed. Expected: go back to the main menu of settings Actual: camera app launches.

This sounds a lot like what I was seeing in bug 823098.

I just saw this with a freshly flashed build of m-c. I was in the Maps app, and clicked the back button to leave the About screen. But it launched the Twitter share app which was in the upper-left corner of the homescreen.

It has happened in e-mail for me a few times, usually triggering the calendar app, because that is the app in the upper-left corner of the app page e-mail lives on. It is still happening with the most recent nightly as of now (the one with the regressed keyboard for focus()).

Yes, Mikeh. I believe you're right. This happens with all apps. On load, when you tap in an area, it's transparently triggering what's lying on the homescreen. ie. for settings app, the back button also coincides with the camera app. for e-mail, the account drawer coincides with the calendar app.

Unfortunately it all sounds too much like a Gecko issue...

I can't reproduce this issue with these steps... :( Do we have to bb+ this one? (In reply to Naoki Hirata :nhirata from comment #10) > Sorry. I misunderstood the issue at the start. > > I can get it to reproduce consistently. > It has to do with the timing of launch of settings and hitting the back > > 1. make sure the settings and camera app is closed using the task manager > 2. launch settings > 3. as soon as settings launches go into a submenu such as network > 4. as soon as it switches, tap the area where the back < would be placed. > > Expected: go back to the main menu of settings > Actual: camera app launches.

(In reply to khu from comment #17) > I can't reproduce this issue with these steps... > :( > > Do we have to bb+ this one? > I think we should; whoever making a comment like the one I did in comment 7 will soon experience this bug ... this is a curse. You will have to reproduce it unintentionally.

i can reproduce occasionally too. i always launch settings from the home screen (this page of the home screen has camera on the upper left corner where the back keys are in settings) i feel that if i tap the area around the back key in settings app randomly (or quickly for a few times as you know that the back key is sometimes missed when you tap it), camera gets launched so it seems like the touch event for a quick instance got the to home screen and that location happens to be camera so camera gets launched.

i am using the 2012/12/25 nightly build (updated through daily FOTA)

It's not a curse. There is no such non-scientific thing. The reason it open up the camera is because gecko didn't handle frames well in certain version. After like maybe 4 days(2012-12-16~2012-12-19). For old versions(2012-12-16~2012-12-19), as for how to reproduce it, if you are in settings app and homescreen happened to have camera app icon on top left, you will be able to trigger the events. If you have gallery on top left corner, it would trigger gallery. If you have the homescreen with clock on the back, "<" button would be totally malfunction. For new version: It has became not that reproducible. But, my way to reproduce it is just click it really fast on anywhere.

Can we please set the blocking status back to +?

It's easier to reproduce the issue in the following steps: 1. Launch the Settings app, and go to any sub-menu that has '<', close the Settings app with home key. 2. Long press the home key and re-launch the Settings from card view. 3. Press '<' and result in launching the Camera app. Actually, if you swipe the homescreen to the second page, where Calendar is the most upper left app, doing steps 1 ~ 3 results in launching the Calendar app. Furthermore, I'm also seeing this issue on other apps too, e.g. launch the Clock app, press home key to close it, re-launch the Clock app from card view, 'press at lower right region where an app icon on the dock is beneath it', also result in launch that app. I've tried backing out gecko to > commit:13512af96db1f5ca11bdf2393fb64c4f027711a6 And did not see this issue, so it's possible that > commit:bfaac36a78b7fa29c62327abb80e1efd2081e6d5 is the first commit that breaks it. Though I'm not 100% sure, can we have QA to verify on this?

Shelly's STR is the best among all the STR. It's really easy to reproduce in that way.

Yes, I reproduce it nearly 100% with these steps. Thanks Shelly this is very helpful ! It also works when clicking top left on the home menu (so, without a back button then). And with other apps as well (just tried with the Email app).

I did just reproduce this per comment 24 (Otoro 2012-12-19) though not on the first try. Marking blocking as we are clearly having a focus or event handling issue somewhere.

why is that qawanted kept got added????????? VERIFIED IN COMMENT25

By bisecting the gecko commits, I found that the check in of https://bugzilla.mozilla.org/show_bug.cgi?id=780692#c240 seems to be the cause of this issue. To test, just turn off the throttle-animations feature from b2g/app/b2g.js original: > pref("layers.offmainthreadcomposition.throttle-animations", true); after: > pref("layers.offmainthreadcomposition.throttle-animations", false); Also, seems that it is the cause of bug 822186 as well, I don't have the fix from bug 822186 yet and the side effect is gone after turning off the throttle-animations feature. I'm guessing it might be a reflow issue to this bug too?

CCing people who were involved with bug #780692.

It sounds like maybe we're not flushing animations when we determine the target of the touch event? Or if we are, we're not doing it correctly.

We do flush animations for touch events: https://mxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#5790

It shouldn't be too hard to figure this out by adding some code to FindFrameTargetedByInputEvent to dump the display list we generate for the touch event that launches the camera app.

In Unagi build 20121231070201, I can still get this behavior although it is MUCH less prevalent than it was before. I was able to repro this issue in FM radio with no headphones in so that the FM Radio launches then a message loads saying you need headphones. During the loading of the headphones message I was able to tap through the FM Radio onto the Camera App on the Home screen. Although there is no back button on the FM Radio screen it displays the same behavior. Please also read my bug on the true nature of this bug. https://bugzilla.mozilla.org/show_bug.cgi?id=823248 I can repro this behavior with other apps such as Music and tapping through to icons on the quick bar which ends up launching those apps as well.

Removed "qawanted" form keywords refer to above comment

Unfortunately, I don't see any telling errors or warnings when I reproduce this in a debug build.

dholbert, possible to help do #35 to help on Friday? Not sure Nick is available until Monday so it would be good to move along in the meantime.

Sure. (Leaving needinfo:myself to remind me to look into this.) FWIW, I was able to reproduce this w/ steps in comment 24, in 2 out of 3 tries.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #35) > It shouldn't be too hard to figure this out by adding some code to > FindFrameTargetedByInputEvent to dump the display list we generate for the > touch event that launches the camera app. I don't have the display list yet, but I made an instrumented build to just print out the frame tree and the returned frame, whenever FindFrameTargetedByInputEvent() is called. Perhaps-unsurprisingly, the frame tree that's printed when this bug reproduces is the tree **for the home screen app**. And the frame that we return corresponds to the camera icon (the first floated item in the frame tree).

Sorry -- I didn't initially notice that there were multiple back-to-back FindFrameTargetedByInputEvent calls for a single event (one in the b2g process, and then one in the child process) -- so that last attachment was just the child process, which isn't really interesting because it's after we've triggered the bug & dispatched the event to the wrong child. So -- here's a frame dump & event-handling display-list dump for when we call FindFrameTargetedByInputEvent in the b2g process, for a screen-touch that reproduced this bug.

For reference, here's the patch I used to generate this log.

I just filed bug 826822, which may be related.

(In reply to Daniel Holbert [:dholbert] from comment #46) > So -- here's a frame dump & event-handling display-list dump for when we > call FindFrameTargetedByInputEvent in the b2g process, for a screen-touch > that reproduced this bug. Thanks. It looks like the toplevel window contains only app://system.gaiamobile.org/index.html, which I assume is the homescreen. No sign of the camera app in the frame tree. That is surprising!

The homescreen should be app://homescreen.gaiamobile.org/index.html; app://system.gaiamobile.org/index.html is the System app. But I don't know how all this work together.

Hmm. Daniel, is there a third page, for the "System app", that contains IFRAMEs for the homescreen and for the camera app? If so we need a dump for that page.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #53) > Hmm. Daniel, is there a third page, for the "System app", that contains > IFRAMEs for the homescreen and for the camera app? I'm guessing you probably meant s/camera/settings/? (I don't think there would be a page for the camera app -- the attached dump is from when the touch is received, which is *just* before we launch the camera app in the first place.)

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #53) > Hmm. Daniel, is there a third page, for the "System app", that contains > IFRAMEs for the homescreen and for the camera app? If so we need a dump for > that page. Is it following? https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/lockscreen.js#L585

(In reply to Sotaro Ikeda [:sotaro] from comment #55) > Is it following? > https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/lockscreen. > js#L585 Nope -- this has nothing to do with the lock screen, and there's nothing special about the camera app aside from its default-icon-placement on the homescreen. (which makes its icon receive the touch when we trigger this bug w/ settings "back" button, since it's directly behind that button)

(In reply to Daniel Holbert [:dholbert] from comment #54) > (In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #53) > > Hmm. Daniel, is there a third page, for the "System app", that contains > > IFRAMEs for the homescreen and for the camera app? > > I'm guessing you probably meant s/camera/settings/? Yes.

Just adding some notes because I have seen this myself. I think I've also found 100% STR. The app does not matter - the tap just goes through to whatever is positioned on the background. Here are the STR I found: - Close all apps on the phone - Launch settings - Tap home - Hold home for card switcher - Open settings app from card switcher - Tap on where an icon should be on the homescreen, or dock. These steps reproduce the bug 100% for me. I'll continue to see if I can provide any help here.

(In reply to Kevin Grandon from comment #58) > The app does not matter - the tap just goes through to whatever is > positioned on the background. Yup -- I'm now using the Calculator app as my test-app. (and launching app-icons behind it) > Here are the STR I found: (those are a slightly-simplified version of comment 24, FWIW) In a debug non-optimized build (with my debug logging, which slows things down further), I've found that this is quite easy to reproduce -- there's a short flash of not-darkened-at-all homescreen after you touch the app in the card view and before it takes full-screen, and if you touch any desktop icon at that point, it'll launch that desktop icon.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #53) > Hmm. Daniel, is there a third page, for the "System app", that contains > IFRAMEs for the homescreen and for the [foreground] app? If so we need a dump for > that page. The dump I posted before was the system app frame-dump, but its frametree didn't descend into its iframe -- turns out I need to give List() a flag ( TRAVERSE_SUBDOCUMENT_FRAMES, which is "1") in order to get that. Here's a revised frame-dump and display-list dump, for a call to FindFrameTargetedByInputEvent that reproduces this. The foreground app I was using was the Calculator, and I touched the screen while the home-screen (briefly) looked like it was the foreground app, between the card-switcher disappearing and the calculator app coming up.

To illustrate this... (In reply to Daniel Holbert [:dholbert] from comment #60) > In a debug non-optimized build (with my debug logging, which slows things > down further), I've found that this is quite easy to reproduce -- there's a > short flash of not-darkened-at-all homescreen after you touch the app in the > card view and before it takes full-screen, and if you touch any desktop icon > at that point, it'll launch that desktop icon. ...and this... (In reply to Daniel Holbert [:dholbert] from comment #61) > I touched the screen while the home-screen > (briefly) looked like it was the foreground app, between the card-switcher > disappearing and the calculator app coming up. ...here's a screencast showing that flash of the fully-brightened home-screen, on my unagi running my debug-logging non-opt build. I wonder if this bug is as simple as e.g. the card-switcher getting backgrounded (and the home-screen being briefly displayed [perhaps too brief to be seen in opt builds]) before the to-be-launched app is ready to come up, or something like that.

er, meant to include a youtube link for screencast in prev comment. that link is: https://www.youtube.com/watch?v=SwHYGQdq8G4

Long ago I filed bug 795399 when events were going through an overlay to the elements beneath it. That was all in a single app, though, not between apps. I mention it here just in case it is related. There's a test case in that bug.

At JP's request, I'm taking this bug, as I think nrc is currently focusing on another blocker.

(In reply to Kevin Grandon from comment #58) > Just adding some notes because I have seen this myself. I think I've also > found 100% STR. > > The app does not matter - the tap just goes through to whatever is > positioned on the background. > > Here are the STR I found: > > - Close all apps on the phone > - Launch settings > - Tap home > - Hold home for card switcher > - Open settings app from card switcher > - Tap on where an icon should be on the homescreen, or dock. > > These steps reproduce the bug 100% for me. I'll continue to see if I can > provide any help here. Using these steps I can also reproduce this bug reliably with the Music and E-mail apps.

(In reply to Daniel Holbert [:dholbert] from comment #62) > I wonder if this bug is as simple as e.g. the card-switcher getting > backgrounded (and the home-screen being briefly displayed [perhaps too brief > to be seen in opt builds]) before the to-be-launched app is ready to come > up, or something like that. Could be, but I wouldn't expect people to think they were clicking on the foreground app in that case. In https://bug822721.bugzilla.mozilla.org/attachment.cgi?id=698821 I don't know why it didn't descend to print out of the homescreen and calculator frame trees, but that is likely not related to this bug. I'm not able to reproduce the bug as described, but I can definitely see some flicker when I open apps from the card view.

(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #67) > In https://bug822721.bugzilla.mozilla.org/attachment.cgi?id=698821 I don't > know why it didn't descend to print out of the homescreen and calculator > frame trees, but that is likely not related to this bug. Possibly because those frame-trees are managed by separate processes.

It looks like the calculator's frame doesn't add any items to the event-handling display list at all, in attachment 698821 [details]... that's interesting.

Duh, of course.

OK -- from single-stepping through parts of the display-list-for-events creation, I noticed we hit this chunk of code for the iframe that we _should_ be sending the touch event to (the calculator, in my case): > nsRect* savedDirty = static_cast<nsRect*> > (child->Properties().Get(nsDisplayListBuilder::OutOfFlowDirtyRectProperty())); > if (savedDirty) { > dirty = *savedDirty; > } else { > // The out-of-flow frame did not intersect the dirty area. We may still > // need to traverse into it, since it may contain placeholders we need > // to enter to reach other out-of-flow frames that are visible. > dirty.SetEmpty(); > } https://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#2121 |child| is the nsSubDocumentFrame there. savedDirty (pulled from its Properties()) is null, so we end up entering that last clause, and triggering the "did not intersect" chunk, setting the dirty rect to empty. That makes us return early via this code: > 2159 // We can stop if child's frame subtree's intersection with the > 2160 // dirty area is empty. > 2161 // If the child is a scrollframe that we want to ignore, then we need > 2162 // to descend into it because its scrolled child may intersect the dirty > 2163 // area even if the scrollframe itself doesn't. > 2164 if (child != aBuilder->GetIgnoreScrollFrame()) { > 2165 nsRect childDirty; > 2166 if (!childDirty.IntersectRect(dirty, child->GetVisualOverflowRect())) > 2167 return NS_OK; https://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#2159 ...and so we never hit nsSubDocumentFrame::BuildDisplayList for this iframe.

That property should have been set by a call to nsDisplayListBuilder::MarkOutOfFlowFrameForDisplay earlier during the construction of that display list.

Ah, OK -- so that function is here: https://mxr.mozilla.org/mozilla-central/source/layout/base/nsDisplayList.cpp#559 When I just encountered this bug (I think), that function returned early for the calculator nsSubDocumentFrame (before setting OutOfFlowDirtyRectProperty) because aDirtyRect didn't intersect with overflowRect. dirtyRect was: x = 2580, y = 1860, width = 1, height = 1 and overflowRect was: x = 3840, y = 5520, width = 11521, height = 16561 That x,y position is what the frame dump in attachment 698821 [details] shows, too, in vis-overflow: > FrameOuter(iframe src=app://calculator.gaiamobile.org/index.html)(8)@0x4beeca98 [view=0x45a5d2e0] {0,1200,19200,27600} [state=000006e000012310] [content=0x45a5d0a0] [vis-overflow=3840,5520,11521,16561] [scr-overflow=3840,5520,11521,16561] [sc=0x4b82fb90]

The visual and scrollable overflow areas are completely wrong because they don't include the border-box of the frame! There's your bug!

Nope, they're actually correct for the app when it's displayed in card-switcher view -- they have this style applied: > #cards-view .card { [...] > transform: scale(0.6); > } https://github.com/mozilla-b2g/gaia/blob/master/apps/system/style/cards_view/cards_view.css#L30 ...which affects the overflow areas in FinishAndStoreOverflow: https://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrame.cpp#6991 (note that the overflow area's width is 11521, which is 0.6 * 19200) SO: When my touch event was received by the home-screen in comment 698821 (bypassing the just-activated-from-cards-view calculator app), we still had the calculator app's frame at its transform:scale(0.6) size. That seems like a bug in the card-switcher mechanics. While the card-switcher UI is up, it (correctly) blocks homescreen touches. I'd expect it to continue to block touches while it's launching your selected app. I wonder if it disables its overlay and tweaks the card style at the same time, but there's a delayed style-flush or something, where the overlay is down and the user can get in some button-presses...

Does it help if PresShell::HandleEvent makes the FlushPendingNotifications(Flush_Layout) call in more than just the NS_TOUCH_EVENT case? (Like, say, maybe any case where dispatchUsingCoordinates, which is set just below that call, is true?)

FWIW, I've seen this happen a significant amount of time after switching to an app, and I'm pretty sure I've seen it after I've been interacting with an app (i.e. switched to the settings app, do some stuff, then hit back, and end up in the camera app). So it doesn't *seem* like this is a matter of a missing flush, but I could be wrong.

Yeah, it doesn't seem to be a timing issue, see comment #24. You don't need to be fast to trigger this issue. You can also scroll the settings subpanel's content, wait a little, and then click the back button to reproduce.

That it's not a timing issue doesn't mean it wouldn't be fixed by a flush (especially if there might be a case where we're not doing the restyling/relayout that we ought to be doing at the end of a throttled animation)

Oh yeah, sorry, that makes sense.

(In reply to Johnny Stenback (:jst, jst@mozilla.com) from comment #77) > I'm pretty sure I've seen it after I've been interacting with an > app (i.e. switched to the settings app, do some stuff, then hit back, and > end up in the camera app). There may be multiple distinct paths by which touch-events make it through to the homescreen from the STR. Right now I'm focusing on whatever's causing trouble in my latest attachment, since that's the sort of thing I've been able to reproduce. (In reply to Tim Taubert [:ttaubert] from comment #78) > Yeah, it doesn't seem to be a timing issue, see comment #24. And I'll counter with "in my case, it does seem to be a timing issue -- see comment 62". :) (and beginning of comment 75 -- notably, we're dispatching touch events to the homescreen there, after the app has been pressed in the app switcher, before its "scale(0.6)" styling has gone away). I am definitely hitting a version of this bug that seems to be a timing issue -- there may be other unrelated ways of triggering similar results, too, but the circumstances that I'm hitting are the easiest to investigate & predictably reproduce in my debug build at the moment, so that's what I'm focusing on.

In any case, comment 76 was a testable question (really just a guess); more useful to test than to speculate. (I can try tomorrow if needed, but I suspect dholbert or others have everything set up to test this better than I do.)

Oh, sorry -- I missed comment 76. I'm heading to bed soon, but I'll try that tomorrow.

OK -- so with some help from vivien and timdream, I confirmed my suspicion at the end of comment 75. When you touch an app in the app-switcher, we start an animation to maximize the app, and as the animation _starts_, we send an "appwillopen" event, which hides the card-switcher UI: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/cards_view.js#L635-L637 So -- if we don't have a great sample-rate, or if the user is just super-speedy, then they'll have a short opportunity to press stuff on the homescreen, from when they press the app in the card-switcher to when the app finishes maximizing. To fix that, we can wait to hide the card-switcher UI until the app has finished maximizing. In particular, s/appwillopen/appopen/ should take care of that. We may still want to make the card-switcher UI _visually_ hide (even though it still is open to block events) during the animation -- we could probably do that by giving it "visibility:hidden" or something like that, when "appwillopen" fires.

(For reference, appwillopen is dispatched here: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/window_manager.js#L956-L961 whereas appopen is dispatched here: https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/window_manager.js#L418-L422 )

That might be one issue, but I do notice this long after the animation is finished.

Hah, interesting. So this fixes the issue for me: https://github.com/KevinGrandon/gaia/compare/bug_822721_z_index_experiment It does have the side effect of hiding icons when you open an app from the card switcher - I bet we could use pointer-events: none as well (instead of z-index). I will play with it. Feel free to assign to me if you'd like.

(Oops - I meant to assign to me only if we're willing to consider this hacky fix. Might be worthwhile at this time.)

Chatted with Kevin a little while ago -- he said the pointer-events alternative in comment 87 didn't end up working for some reason, so we've got his z-index workaround with the slightly-jarring effect of making the homescreen app icons disappear when homescreen isn't foreground. I'm going to try something along the lines of Comment 84, which might be a cleaner fix.

(In reply to David Baron [:dbaron] from comment #76) > Does it help if PresShell::HandleEvent makes the > FlushPendingNotifications(Flush_Layout) call in more than just the > NS_TOUCH_EVENT case? (Like, say, maybe any case where > dispatchUsingCoordinates, which is set just below that call, is true?) This doesn't help.

So the steps in comment 24 show the bug (starting the camera app) pretty reliably for me. But they stop showing the bug if I change: -pref("layers.offmainthreadcomposition.animate-transform", true); +pref("layers.offmainthreadcomposition.animate-transform", false); They also stop showing the bug if I change (independently of the above): -pref("layers.offmainthreadcomposition.throttle-animations", true); +pref("layers.offmainthreadcomposition.throttle-animations", false); So there's still something going on here with throttling (i.e., suppressing the reflection into style and layout) of animations of transform.

Also worth noting that: -pref("layers.offmainthreadcomposition.animate-opacity", true); +pref("layers.offmainthreadcomposition.animate-opacity", false); doesn't affect whether the bug happens. I thought it was worth testing since there was a transition of opacity on another element (I think the parent) outside of the element on which we're transitioning transform.

I was able to reproduce the bug using comment 24's steps almost every time; with this patch I was unable to see the bug three times in a row.

And the stuff in comment 73 / comment 75 / etc. that dholbert found about the overflow areas being wrong was the key to figuring out that the style change processing was missing here, by the way.

Comment on attachment 699543 [details] [diff] [review] patch Nice catch! r=me

(FWIW, I tried to come up with some gaia fix per comment 84 / end of comment 89, but those patches had side effects that I wasn't happy about.) Glad to hear that dbaron found the underlying platform bug! Reassigning to him, since the ultimate patch here is his.

I'm not waiting for nrc's review now that I realize his in Berlin rather than New Zealand. Still interested, though, particularly on the two "FIXME" comments. https://hg.mozilla.org/integration/mozilla-inbound/rev/cbd9b6dfc7d9 https://hg.mozilla.org/integration/mozilla-inbound/rev/3a96ce34c5d6 https://hg.mozilla.org/releases/mozilla-b2g18/rev/79a4f6d50863

Comment on attachment 699543 [details] [diff] [review] patch Review of attachment 699543 [details] [diff] [review]: ----------------------------------------------------------------- I don't understand the changelist stuff at all, but I don't see anything that looks broken, so r=me for that. I'll test whether we still need to force rerendering of the layer in bug 828173. I suspect we still do, but as I say, I don't understand the changelist stuff, so we'll see.

Backed out of b2g18 for assertions and then timeout during test_transitions_and_zoom.html: https://tbpl.mozilla.org/php/getParsedLog.php?id=18618807&full=1&branch=mozilla-b2g18#error0 https://hg.mozilla.org/releases/mozilla-b2g18/rev/25df46dc95b9

Is green on inbound for some reason.

https://hg.mozilla.org/mozilla-central/rev/e349cfb9114f https://hg.mozilla.org/mozilla-central/rev/9a99dad5b253

https://hg.mozilla.org/mozilla-central/rev/cbd9b6dfc7d9 https://hg.mozilla.org/mozilla-central/rev/3a96ce34c5d6

(In reply to Ed Morley [:edmorley UTC+0] from comment #99) > Backed out of b2g18 for assertions and then timeout during > test_transitions_and_zoom.html: (In reply to Ed Morley [:edmorley UTC+0] from comment #100) > Is green on inbound for some reason. It looks like that's just because inbound & m-c don't get test-runs for the failing platform (B2G Arm debug).

Ah, the assertion was wrong; I missed the if (HasTransformStyle() != aOther.HasTransformStyle()) case in nsStyleDisplay::CalcDifference, and I should probably just skip it since the cases are likely to evolve over time. I'll remove it from inbound and reland on b2g18 without it.

https://hg.mozilla.org/integration/mozilla-inbound/rev/dff10a89c17c https://hg.mozilla.org/releases/mozilla-b2g18/rev/4f39c1a71383

I just reproduced this* in today's just-released build, 20130109070203, which has Git commit info: 2013-01-09 11:30:18 f8e15c1774... I don't know what that Git Commit Info timestamp corresponds to exactly, but the time is 2 1/2 after the mozilla-b2g18 landing from comment 105. Do we know if that means this build should include the fix? * I reproduced it when tapping "back" from bluetooth area of Settings app.

(comment 108 is for a "beta" build for unagi, FWIW)

I don't think we're landing patches in the beta tree anymore. Just on m-c and b2g18, so your build may not have this patch.

(I'm not talking about hg.mozilla.org/releases/mozilla-beta -- I'm talking about the "beta" channel that B2G unagi dogfooders are on, which is receiving daily updates at this point, and which I assume are built off of some gecko branch that's receiving updates.) FWIW, I've been told that that the git commit from comment 108 corresponds to a gaia repo (though I can't seem to find that commit ID in gaia's git log, but that's a different issue). So for now, I'm going to assume that my dogfood build narrowly missed getting this bug's fix, and that it'll hopefully be fixed in tomorrow's dogfood build...

(In reply to Daniel Holbert [:dholbert] from comment #111) > > FWIW, I've been told that that the git commit from comment 108 corresponds > to a gaia repo (though I can't seem to find that commit ID in gaia's git > log, but that's a different issue). It's definitely not a gaia patch. We suspected that we might have two issues causing the same problem so you might have found the second issue. It may make sense to clone this bug then.

(In reply to Julien Wajsberg [:julienw] from comment #112) > > FWIW, I've been told that that the git commit from comment 108 corresponds > > to a gaia repo > > It's definitely not a gaia patch. (I wasn't talking about this bug's patch, I was talking about my git commit ID in the Settings app "Git Commit Info" section.) (In reply to Daniel Holbert [:dholbert] from comment #111) > So for now, I'm going to assume that my dogfood build narrowly missed > getting this bug's fix I verified that that's the case. The sources.xml file for my build ID[1] shows that my build was generated using gecko from https://hg.mozilla.org/releases/mozilla-b2g18/rev/03cdcbfecb2c , which was a few hours before comment 105. [1] https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi_betatest/2013/01/2013-01-09-07-02-03/sources.xml So - sorry for concern, no need to worry yet. If we can reproduce this in builds later than today's beta release (20130109070203), then we can start worrying & clone this bug per comment 112.

Hi, It was quite reproducible last week. However, it quite stable this Monday. Mark this as verified fixed. Device: Unagi Build Identifier: 20130113070202 Update channel: nightly b2g18 (pvt server) unagi.zip 13-Jan-2013 08:06 100M https://pvtbuilds.mozilla.org/pub/mozilla.org/b2g/nightly/mozilla-b2g18-unagi-eng/ Git commit info: 2013-11-13 15:15:51