Popping out Loop video doesn't resize window correctly (self-view partly hidden)

RESOLVED WORKSFORME

Status

P1
normal
RESOLVED WORKSFORME
4 years ago
4 years ago

People

(Reporter: whimboo, Unassigned)

Tracking

unspecified
x86_64
Linux
Points:
---
Bug Flags:
in-moztrap +
qe-verify +

Firefox Tracking Flags

(firefox34 wontfix, firefox35 verified, firefox36 unaffected)

Details

Attachments

(2 attachments)

(Reporter)

Description

4 years ago
Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101 Firefox/34.0 ID:20141001004005 CSet: c20912812877

When you get and accept a loop call, you will have a small window with the video on the lower right side. Trying to maximizing (popping-out?) it, the size is not perfectly chosen, so that the self-view is visible partly and scrollbars exist.

It would be good if the full video and self-view is shown when the video gets maximized.
I just ran into a variant of this problem. "Maximizing" with the diagonal arrow in the title bar resulted in a slightly bigger popup window that had white space for half of the window. This was on today's Aurora, 34.0a2 (2014-10-07).  Attaching a screenshot.
Created attachment 8501385 [details]
Screenshot of Loop popup window resize problem with whitespace.
backlog: --- → Fx35+

Updated

4 years ago
Priority: -- → P1

Comment 3

4 years ago
it was resolved enough along the way.  please validate.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
Henrik/Liz, could you please confirm this is no longer an issue?
Flags: needinfo?(lhenry)
Flags: needinfo?(hskupin)
Created attachment 8520008 [details]
loop-34b7-whitespace.png

White space under the video area when the window is popped out/maximized.
Flags: needinfo?(lhenry)
I'm still seeing the issue in 34.0b7 on MacOSX 10.8.5 (see attachment above)
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Liz -- Can you try this on Nightly and Aurora?
Flags: needinfo?(lhenry)
It looks great in Nightly with e10s on and off, either way. 
In Aurora 35, it's still broken.
Flags: needinfo?(lhenry)
status-firefox34: --- → affected
status-firefox35: --- → affected
status-firefox36: --- → unaffected
Flags: needinfo?(hskupin)
Liz, can you retest with the most recent Aurora (built last night)?  We uplifted a few bug fixes yesterday, and I believe one of them fixed this bug.  

I think it's too late to try to land this fix on Fx34 (since we have less than 2 weeks to release).  So if it works on Fx35 with the latest uplifts, I suggest we mark this Resolved/WorksForMe.

Thanks!
Flags: needinfo?(lhenry)
Maire, no problem. Looks great in last night's Aurora: 35.0a2 (2014-11-11)

I'm fine with it not uplifting to 34. It doesn't break any functionality. It just looks a bit clunky!
Flags: needinfo?(lhenry) → needinfo?(anthony.s.hughes)
Thanks, Liz.  Based on this information, I'm going to mark this WorksForMe.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
status-firefox34: affected → wontfix
status-firefox35: affected → fixed
Resolution: --- → WORKSFORME
Flags: needinfo?(anthony.s.hughes)
status-firefox35: fixed → verified
Flags: qe-verify+
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.