1141128 - Add margin to the left side of the remote video container in the standalone client

Status: VERIFIED FIXED

(Hello (Loop) :: Client, defect, P2)

Description

[Mike de Boer [:mikedeboer]]

During the Window/ tabsharing feature review the issue was raised that the remote video stream hugs the left side of the tab/ window too much.

Sevaan noted that adding a margin/ padding if 10px would make it look much better.

Comment 1

[Sevaan Franks [:sevaan]]

Attachment: 10px Left Margin

Comment 2

[Mike de Boer [:mikedeboer]]

Attachment: Patch v1: add a margin of 10px to the left side of the remote video stream

Comment 3

[:shell escalante]

Per Gavin's request - just updating bugs that carried over before they were 100% resolved to the next iteration.

Comment 4

[Mark Banner (:standard8)]

Comment on attachment 8575315 [details] [diff] [review]
Patch v1: add a margin of 10px to the left side of the remote video stream

Review of attachment 8575315 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.

Comment 5

[Mike de Boer [:mikedeboer]]

Thanks! Pushed to fx-team as: https://hg.mozilla.org/integration/fx-team/rev/289f3a6723bc

Comment 6

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/289f3a6723bc

Comment 8

[Bogdan Maris, Desktop QA]

I tested this fix across platforms (Windows 7 64-bit, Mac OS X 10.9.5 and Ubuntu 14.04 32-bit) on latest Nightly. I noticed that the padding only applies when the sharing is active, not before entering the conversation and after leaving it. Is this the intended behavior?

Comment 9

[Mike de Boer [:mikedeboer]]

Hi Bogdan, I'm afraid this bug is not yet verifiable, because this fix is only available when the standalone client is updated on 'hello.firefox.com'.
So this is not part of the UI inside Firefox.

That said, I think it'd be good leave a note in the bugs that went into the standalone client once an update is released, so that the verification process can be kicked off from then on.

Comment 10

[Mike de Boer [:mikedeboer]]

Mark, please see comment 9. Is this feasible with the current release automation? Or can I file a bug to get this done at some point?

Comment 11

[Mark Banner (:standard8)]

(In reply to Mike de Boer [:mikedeboer] from comment #9)
> Hi Bogdan, I'm afraid this bug is not yet verifiable, because this fix is
> only available when the standalone client is updated on 'hello.firefox.com'.
> So this is not part of the UI inside Firefox.

This should, however, be verifiable on the development server - set your loop.server pref to "https://loop-dev.stage.mozaws.net/v0" (I recommend doing this in a separate profile).

> That said, I think it'd be good leave a note in the bugs that went into the
> standalone client once an update is released, so that the verification
> process can be kicked off from then on.

I think generally I'd prefer verification against the development servers - as then we can find issues before it hits production.

Generally it hits development within an hour of the bug being marked as "fixed".

That said, it might also be good to see if we can automatically comment on the bug for when it goes to production anyway. That way we can have tracking for future, to know exactly when a bug shipped. Its conceivable that we could roll this into automation that ops are already working on. Getting bug 1050295 would probably also help this work.

Might be worth thinking a little bit more about the exact flow that we want before we file bugs though.

Comment 12

[Bogdan Maris, Desktop QA]

(In reply to Mark Banner (:standard8) from comment #11)
> (In reply to Mike de Boer [:mikedeboer] from comment #9)
> > Hi Bogdan, I'm afraid this bug is not yet verifiable, because this fix is
> > only available when the standalone client is updated on 'hello.firefox.com'.
> > So this is not part of the UI inside Firefox.
> 
> This should, however, be verifiable on the development server - set your
> loop.server pref to "https://loop-dev.stage.mozaws.net/v0" (I recommend
> doing this in a separate profile).
> 
> > That said, I think it'd be good leave a note in the bugs that went into the
> > standalone client once an update is released, so that the verification
> > process can be kicked off from then on.

Thanks Mark, I changed the value of loop.server and I verified that this issue is fixed on Windows 8.1 64-bit, Mac OS X 10.9.5 and Ubuntu 14.04 32-bit using latest Nightly.