vsireesha246 Reporter
	Description • 10 years ago

STR:

1.Open video app with videos in device
2.Play any video from thumbnail list
3.Click on ... or options icon
4.Click on Share
5.Select Messaging->The File you select is too large pop up will be shown

Actual:Video play continues and same behavior is observed in Bluetooth share as well

But in Share through Email is causing the video to pause.

	vsireesha246 Reporter
	Comment 1 • 10 years ago

Hi Alive,

Should you please check this issue.
Video share via Email is getting visibility change event and causing video app to pause.
But same is not happening for SMS and BT.

Thanks..
Sireesha

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 2 • 10 years ago

This is working as expected.
Share through e-mail is opening a new appWindow (window disposition activity)
but share through other inline activity will not put the activity caller to background (to trigger audio competing policy to work.)

The root cause is coupling of
1. page visibility and process priority
2. page visibility and audio competing policy

If we put the activity caller to background it will become low priority process and easily to be killed.

	Julien Wajsberg [:julienw]
	Comment 3 • 10 years ago

Hey Alive,

it feels strange that if the page is hidden, we don't have the page visibility sent. I think this can make all sort of subtle bugs.
For example, the SMS app relies on the page visiblity hidden to store drafts. We can't know if an activity is inline or window, so when we trigger an activity, we rely on the fact that the window will be hidden and the page visibility sent to save a draft.

I see it's the same idea in Video.

So we definitely need this event. I understand what you say with coupling, but we definitely need a way to say "this page is not visible but is still foreground".

	(inactive after 6/18) Alive Kuo [:alive]
	Comment 4 • 10 years ago

(In reply to Julien Wajsberg [:julienw] from comment #3)
> Hey Alive,
> 
> it feels strange that if the page is hidden, we don't have the page
> visibility sent. I think this can make all sort of subtle bugs.
> For example, the SMS app relies on the page visiblity hidden to store
> drafts. We can't know if an activity is inline or window, so when we trigger
> an activity, we rely on the fact that the window will be hidden and the page
> visibility sent to save a draft.
> 
> I see it's the same idea in Video.
> 
> So we definitely need this event. I understand what you say with coupling,
> but we definitely need a way to say "this page is not visible but is still
> foreground".

Are you proposing a new and general event, other than visibilitychange, before we implement bug 892371? And we will deprecate it after the priority issue is resolved?
I cannot sign off on that kind of event, if you can convince webapi folks I could support to implement in gaia. But we definitely needs gecko help to realize that.

	Julien Wajsberg [:julienw]
	Comment 5 • 10 years ago

I was more proposing something that would send the visibilitychange event without changing the adj score. But maybe that's what you intend to do in bug 892371 already?

	Julien Wajsberg [:julienw]
	Comment 7 • 10 years ago

Hey Gabriele,

maybe you can comment on what's happening here?

	Gabriele Svelto [:gsvelto]
	Comment 8 • 10 years ago

Alive's description of the problem is accurate. Currently the system app flags activity openers as visible to prevent the process priority manager from demoting them to background status which could cause them to die. My fix for bug 892371 only addressed a specific problem (chain of activities) but doesn't solve this. I'm opening a follow up and will make this bug block on it; in the meantime I'm confirming this.

	Gabriele Svelto [:gsvelto]
	Comment 9 • 9 years ago

I've just verified that this is fixed, most likely after bug 1144132 was fixed.