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)


(Hello (Loop) :: Client, defect)

Not set


(firefox46 unaffected, firefox47+ fixed, firefox48 verified)

Tracking Status
firefox46 --- unaffected
firefox47 + fixed
firefox48 --- verified


(Reporter: arni2033, Assigned: bdahl)



(Keywords: regression)


(2 files, 2 obsolete files)

>>>   My Info:   Win7_64, Nightly 48, 32bit, ID 20160312030405
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

 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.

 In Step 5 and Step 6 there shuld be some content displayed in Hello panel

1) This is regression between Firefox 44 and Firefox 48 (2016.03.12)
2) The same happens with "Share this page" panel.
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

 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
Attachment #8732971 - Flags: review?(cam)
Tracked for Fx47 as it's a new regression.
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.

Attachment #8732971 - Attachment is obsolete: true
Attachment #8734194 - Flags: review?(cam)
Comment on attachment 8734194 [details] [diff] [review]

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.
chrome.ini, rather.
Good catch, had it sitting in staging.

New Try:
Attachment #8734194 - Attachment is obsolete: true
Attachment #8734198 - Flags: review?(cam)
Attachment #8734198 - Flags: review?(cam) → review+
Keywords: checkin-needed
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla48
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]

Fix was verified, Aurora47+
Attachment #8735499 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Keywords: checkin-needed
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)
Flags: needinfo?(bdahl)
Keywords: checkin-needed
Did you try the a+ patch or the original? The a+ one seems to apply cleanly for me.
Flags: needinfo?(cbook)
Flags: needinfo?(cbook)
Dropping obsolete NI.
Flags: needinfo?(bdahl)
You need to log in before you can comment on or make changes to this bug.