On Android, when opening a new chrome window its content is white. Resizing eg. by changing orientation causes the content to be painted.
Created attachment 494174 [details] [diff] [review] wip Android sends resize events only when the surface view change (in GeckoSurfaceView::surfaceChanged()). This method sends a SIZE_CHANGED event to gecko. The approach here is to remember the last SIZE_CHANGED event and resend it to force a resize when we put a window to front. The front-end gets events, but ignores them because the event target is not set correctly. I also tried to simply call OnSizeChanged(gAndroidBounds) in BringToFront(), with no better results.
Created attachment 494868 [details] [diff] [review] wip 2 This new patch makes sure that the child windows of the toplevel one get also resized as they should. But even if their OnResizeHandler() is called, the front-end still tells that the event's target is not the good window.
Comment on attachment 494868 [details] [diff] [review] wip 2 Review of attachment 494868 [details] [diff] [review]: ----------------------------------------------------------------- overall this looks fine, just a few questions about the implementation details ::: widget/src/android/AndroidJavaWrappers.cpp @@ +355,5 @@ > + mTime = other->mTime; > + mP0.x = other->mP0.x; > + mP0.y = other->mP0.y; > + mP1.x = other->mP1.x; > + mP1.y = other->mP1.y; why not use a copy constructor and add a method to change the type? ::: widget/src/android/nsAppShell.cpp @@ +73,4 @@ > nsAccelerometerSystem *gAccel = nsnull; > nsIGeolocationUpdate *gLocationCallback = nsnull; > > +nsAutoPtr<mozilla::AndroidGeckoEvent> gLastSizeChanged; Can we just construct a new event based on mBounds rather than keep a reference to the old event?
Fabrice, what's the plan here?
We currently don't plan to open new chromeless windows for apps, so we are not blocked by this bug anymore.
(In reply to comment #5) > We currently don't plan to open new chromeless windows for apps, so we are > not blocked by this bug anymore. But we do open new windows for other things. Currently, we open the Locale Picker in a new window. After the locale is "picked", the browser.xul window is opened. We have the same hack/fix in browser.js for locale picker as we did for webapps. We should fix this issue.
Created attachment 551792 [details] [diff] [review] Store the last SIZE_CHANGED event, and resend it for new windows, bug 610834
Comment on attachment 551792 [details] [diff] [review] Store the last SIZE_CHANGED event, and resend it for new windows, bug 610834 This fixes it for me.
Backed out because of a tp4m regression (bug 678261): https://hg.mozilla.org/integration/mozilla-inbound/rev/6a9dabc3f3d1
(In reply to Matt Brubeck (:mbrubeck) from comment #11) > Backed out because of a tp4m regression (bug 678261): > https://hg.mozilla.org/integration/mozilla-inbound/rev/6a9dabc3f3d1 It's strange that this patch would have regressed Tp. We only open 1 XUL (app) window for the Tp4 test. A set of webpages are then loaded into the browser. I wonder if this patch was firing a chrome event for triggers from web content DOM windows? Ts wasn't affect so it seems like we were doing a tiny bit of extra work compounded over ~30 pageloads that happen during Tp testing. The single window open that happens during Ts wasn't enough to cause a regression.
Without this patch, the window size is totally busted during the Talos runs. With the patch it is correct. So I think the regression must just be a side effect of having a correct window size. I also checked that no additional resizes are being generated.
Re-landed on inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/46b3d16fc427 I posted a message to dev-tree-management about the expected tp4m hit.
What is a chrome window and how to open one? I am trying to verify this bug :).
The easiest way to make sure things are still working: 1) Set android device locale to something obscure 2) 'clear data' for the fennec application 3) Start fennec and see the locale picker 4) Pick a locale 5) Profit If in the end the browser window is sized correctly, then things are working as intended.
Verified fixed following the steps from comment 17, build: Mozilla /5.0 (Android;Linux armv7l;rv:8.0a2) Gecko/20110828 Firefox/8.0a2 Fennec/8.0a2 Device: LG Optimus 2X