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)

Categories

(Hello (Loop) :: Client, defect)

defect
Not set

Tracking

(firefox46 unaffected, firefox47+ fixed, firefox48 verified)

VERIFIED FIXED
mozilla48
Tracking Status
firefox46 --- unaffected
firefox47 + fixed
firefox48 --- verified

People

(Reporter: arni2033, Assigned: bdahl)

References

Details

(Keywords: regression)

Attachments

(2 files, 2 obsolete files)

>>>   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.
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)
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.

Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=42647c2a67df
Attachment #8732971 - Attachment is obsolete: true
Attachment #8734194 - Flags: review?(cam)
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.
chrome.ini, rather.
Good catch, had it sitting in staging.

New Try:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=fb927fc9b13e
Attachment #8734194 - Attachment is obsolete: true
Attachment #8734198 - Flags: review?(cam)
Attachment #8734198 - Flags: review?(cam) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/e0f03a6f1c8c
Status: ASSIGNED → RESOLVED
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
Status: RESOLVED → VERIFIED
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+
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.