Closed Bug 1256084 Opened 4 years ago Closed 4 years ago
Hello/Share panels don't display anything after I switch window's mode twice (normal/maximized)
>>> My Info: Win7_64, Nightly 48, 32bit, ID 20160312030405 STR: 0. Move Hello button to the start of Navigation toolbar, hide Titlebar, Bookmarks Toolbar, Menu bar 1. Maximize Firefox window (Win+Up) 2. Click Hello button to open panel. Click Hello button to close panel 3. Switch window to Normal mode (or, better: dock it to the right side of screen - Win+Left) 4. Click Hello button to open panel. Click Hello button to close panel 5. Repeat Steps 1-2 6. Repeat Steps 3-4 AR: In Step 2 and Step 4 Hello panel displays some expected content. In Step 5 and Step 6 Hello panel is completely blank/white. No content. ER: In Step 5 and Step 6 there shuld be some content displayed in Hello panel Notes: 1) This is regression between Firefox 44 and Firefox 48 (2016.03.12) 2) The same happens with "Share this page" panel.
[Tracking Requested - why for this release]: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=1f797f47e312c4ab9883bd48c9e3501619ff9e95&tochange=406ee0a64991a8a9bc6b8ef9e1a27a16e80b9b15
I've done some initial investigation. As noted this also seems to happen with the pocket panel. For me easier STR are: 1. Open ff 2. Open hello or pocket panel 3. Do win+right 4. Do win+right AR Panel is blank I've also noticed that even without my changes applied the panel will occasionally be in the wrong location. This probably needs to be filed as a separate bug, but it may be related. Looking into this further...
This fixes the windows regression, but I still think there's another underlying bug. For some reason, triggering a reflow on html popup panels on Windows causes them to become blank. There are several other bugs open that report that the panels go blank and I'm guessing they're caused by the same issue. One thing I notice is that when the panel goes blank the innerWidth is 0. However, if I increase the size of the panel by a couple of pixels it repaints correctly.
Assignee: nobody → bdahl
Status: NEW → ASSIGNED
Attachment #8732971 - Flags: review?(cam)
I think the patch is right, as: * changing eRestyle_Subtree to nsRestyleHint(0) should make no difference, since MediaFeatureValuesChanged will add eRestyle_Subtree if it discovers that the @media rule matching state has changed * NS_STYLE_HINT_REFLOW doesn't need to be passed in, since we should generate reflow change hints in response to restyling To confirm this, could you just add a test that has some rules inside an @media (display-mode: ...) that would require reflow (say, a change to the width or height of an element)?
Attachment #8732971 - Flags: review?(cam) → feedback+
As noted in IRC, the test fails if I comment out the call to MediaFeatureValuesChangedAllDocuments, but works if I leave it in with the changes. Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=42647c2a67df
Comment on attachment 8734194 [details] [diff] [review] 0001-Bug-1256084-Don-t-force-reflow-on-size-mode-change.patch Review of attachment 8734194 [details] [diff] [review]: ----------------------------------------------------------------- Looks good, thanks!
Attachment #8734194 - Flags: review?(cam) → review+
Oh, you might be missing an extra entry in mochitest.ini to run the test.
Good catch, had it sitting in staging. New Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=fb927fc9b13e
Attachment #8734198 - Flags: review?(cam) → review+
Affected: Win7_64, Nightly 48, 32bit, ID 20160325085113 Fixed on: Win7_64, Nightly 48, 32bit, ID 20160326030430
Approval Request Comment [Feature/regressing bug #]: 1104916 [User impact if declined]: hello panel goes blank after window resize (windows only) [Describe test coverage new/current, TreeHerder]: new test makes sure we don't regress display-mode, but there is still some test coverage lacking for HTML panels [Risks and why]: low risk, only could affect new css display mode feature [String/UUID change made/needed]: none
Attachment #8735499 - Flags: approval-mozilla-aurora?
Comment on attachment 8735499 [details] [diff] [review] 0001-Bug-1256084-Don-t-force-reflow-on-size-mode-change.patch Fix was verified, Aurora47+
Attachment #8735499 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
has problems uplifting : merging layout/base/nsPresContext.cpp merging layout/style/test/chrome/chrome.ini merging layout/style/test/mochitest.ini warning: conflicts while merging layout/style/test/chrome/chrome.ini! (edit, then use 'hg resolve --mark') abort: unresolved conflicts, can't continue (use hg resolve and hg graft --continue)
Did you try the a+ patch or the original? The a+ one seems to apply cleanly for me.
Dropping obsolete NI.
4 years ago
You need to log in before you can comment on or make changes to this bug.