Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
visibilitychange events to hidden iframes?
402 views
Skip to first unread message
Tim Guan-tin Chien
Apr 25, 2012, 3:19:23 AM4/25/12
to dev...@lists.mozilla.org
So in Gecko we got Visibility API to tell pages to stop burning CPUs if
the user had switched to other tabs:
https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API
In Gaia we need to do similar notification to apps; since all Gaia apps
are in <iframe mozbrowser>, their visibility states is in sync with the
parent document, and display:none does not trigger visibilitychange.
So that leave us few choices:
A) extend mozbrowser for it to update visibility status when the
window_manager.js request it
B) talk to w3c, modify the behavior of Page Visibility API, decouple the
visibility status of iframes with its parent document all together, and
update the status as the iframe being hidden in CSS
C) invent some kind of Window Manager Notification API (worse choice!)
I think we need to get some ideas first which option is easier to
implement in Gecko. Maybe determining the visibility of a child iframe
is really hard?
Tim
the user had switched to other tabs:
https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API
In Gaia we need to do similar notification to apps; since all Gaia apps
are in <iframe mozbrowser>, their visibility states is in sync with the
parent document, and display:none does not trigger visibilitychange.
So that leave us few choices:
A) extend mozbrowser for it to update visibility status when the
window_manager.js request it
B) talk to w3c, modify the behavior of Page Visibility API, decouple the
visibility status of iframes with its parent document all together, and
update the status as the iframe being hidden in CSS
C) invent some kind of Window Manager Notification API (worse choice!)
I think we need to get some ideas first which option is easier to
implement in Gecko. Maybe determining the visibility of a child iframe
is really hard?
Tim
JOSE MANUEL CANTERA FONSECA
Apr 25, 2012, 3:37:17 AM4/25/12
to Tim Guan-tin Chien, dev...@lists.mozilla.org
El 25/04/12 09:19, "Tim Guan-tin Chien" <timd...@mozilla.com> escribió:
>So in Gecko we got Visibility API to tell pages to stop burning CPUs if
>the user had switched to other tabs:
>
>https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API
>
>In Gaia we need to do similar notification to apps; since all Gaia apps
>are in <iframe mozbrowser>, their visibility states is in sync with the
>parent document, and display:none does not trigger visibilitychange.
I think in the future <iframe mozapp> contexts should be totally decoupled
from the Top Level Browsing Context. Thus, We shouldn't have such a
problem ...
>
>So that leave us few choices:
>
>A) extend mozbrowser for it to update visibility status when the
>window_manager.js request it
>B) talk to w3c, modify the behavior of Page Visibility API, decouple the
>visibility status of iframes with its parent document all together, and
>update the status as the iframe being hidden in CSS
>C) invent some kind of Window Manager Notification API (worse choice!)
>
>I think we need to get some ideas first which option is easier to
>implement in Gecko. Maybe determining the visibility of a child iframe
>is really hard?
>
>
>Tim
>_______________________________________________
>dev-b2g mailing list
>dev...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-b2g
>
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
>So in Gecko we got Visibility API to tell pages to stop burning CPUs if
>the user had switched to other tabs:
>
>https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API
>
>In Gaia we need to do similar notification to apps; since all Gaia apps
>are in <iframe mozbrowser>, their visibility states is in sync with the
>parent document, and display:none does not trigger visibilitychange.
from the Top Level Browsing Context. Thus, We shouldn't have such a
problem ...
>
>So that leave us few choices:
>
>A) extend mozbrowser for it to update visibility status when the
>window_manager.js request it
>B) talk to w3c, modify the behavior of Page Visibility API, decouple the
>visibility status of iframes with its parent document all together, and
>update the status as the iframe being hidden in CSS
>C) invent some kind of Window Manager Notification API (worse choice!)
>
>I think we need to get some ideas first which option is easier to
>implement in Gecko. Maybe determining the visibility of a child iframe
>is really hard?
>
>
>Tim
>dev-b2g mailing list
>dev...@lists.mozilla.org
>https://lists.mozilla.org/listinfo/dev-b2g
>
Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at
http://www.tid.es/ES/PAGINAS/disclaimer.aspx
Vivien
Apr 25, 2012, 3:43:13 AM4/25/12
to JOSE MANUEL CANTERA FONSECA, dev...@lists.mozilla.org, Tim Guan-tin Chien
On 25/04/2012 09:37, JOSE MANUEL CANTERA FONSECA wrote:
> El 25/04/12 09:19, "Tim Guan-tin Chien" <timd...@mozilla.com> escribió:
>
>> So in Gecko we got Visibility API to tell pages to stop burning CPUs if
>> the user had switched to other tabs:
>>
>> https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API
>>
>> In Gaia we need to do similar notification to apps; since all Gaia apps
>> are in <iframe mozbrowser>, their visibility states is in sync with the
>> parent document, and display:none does not trigger visibilitychange.
> I think in the future <iframe mozapp> contexts should be totally decoupled
> from the Top Level Browsing Context. Thus, We shouldn't have such a
> problem ...
>
>> So that leave us few choices:
>>
>> A) extend mozbrowser for it to update visibility status when the
>> window_manager.js request it
>> B) talk to w3c, modify the behavior of Page Visibility API, decouple the
>> visibility status of iframes with its parent document all together, and
>> update the status as the iframe being hidden in CSS
>> C) invent some kind of Window Manager Notification API (worse choice!)
>>
>> I think we need to get some ideas first which option is easier to
>> implement in Gecko. Maybe determining the visibility of a child iframe
>> is really hard?
>>
A) is probably the easiest way to go and there is a bug about that:
> El 25/04/12 09:19, "Tim Guan-tin Chien" <timd...@mozilla.com> escribió:
>
>> So in Gecko we got Visibility API to tell pages to stop burning CPUs if
>> the user had switched to other tabs:
>>
>> https://developer.mozilla.org/en/DOM/Using_the_Page_Visibility_API
>>
>> In Gaia we need to do similar notification to apps; since all Gaia apps
>> are in <iframe mozbrowser>, their visibility states is in sync with the
>> parent document, and display:none does not trigger visibilitychange.
> I think in the future <iframe mozapp> contexts should be totally decoupled
> from the Top Level Browsing Context. Thus, We shouldn't have such a
> problem ...
>
>> So that leave us few choices:
>>
>> A) extend mozbrowser for it to update visibility status when the
>> window_manager.js request it
>> B) talk to w3c, modify the behavior of Page Visibility API, decouple the
>> visibility status of iframes with its parent document all together, and
>> update the status as the iframe being hidden in CSS
>> C) invent some kind of Window Manager Notification API (worse choice!)
>>
>> I think we need to get some ideas first which option is easier to
>> implement in Gecko. Maybe determining the visibility of a child iframe
>> is really hard?
>>
https://bugzilla.mozilla.org/show_bug.cgi?id=702880
B) From what I have understood, reaching a consensus on this has failed
by the past. Since <iframe mozbrowser> are different this will be a
different subject now. But I guess <iframe mozbrowser> needs to be
standardized first.
Vivien.
0 new messages