Visibility notify event API for windowless plugins

RESOLVED FIXED

Status

()

Core
Plug-ins
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: romaxa, Assigned: dougt)

Tracking

Trunk
Other
Linux
Points:
---

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

9 years ago
For windowless plugins on mobile device it is important to know about their visibility state... 

For example if we have > 1 windows with various flash video or some other content, it would be nice to have some way to notify plugins are they visible or not. and plugins can decide to suspend some video decoding or switch games to pause state in case if they are on background (not visible window)...

Currently I cannot find any existing code or API to implement such notifications...

Can someone advice what is the best way to do that?
What about stuff like tab preview? Are you OK to display the old contents for hidden tabs?

Comment 2

9 years ago
You might not need a new API. On Mac OS X we send NPP_SetWindow(NULL) when hiding a plugin behind another tab, you may be able to send NPP_SetWindow(NULL) on Windows/Linux mobile in a different case, for overlapping windows (not just tabs).
(Reporter)

Comment 3

9 years ago
(In reply to comment #1)
> What about stuff like tab preview? Are you OK to display the old contents for
> hidden tabs?

I think it is ok, and it is more important to have better performance for current active page than update all the time all pages, and have whole device busy because all pages working, and rendering actively...
(Reporter)

Comment 4

9 years ago
> You might not need a new API. On Mac OS X we send NPP_SetWindow(NULL) when
> on Windows/Linux mobile in a different case, for overlapping windows (not just
> tabs).

Yep, I know that I can send some event to plugin... but I was thinking what the best way to do that:
1) Implement separate plugin enumerator for DOMwindow, and send event for each plugin.
2) Or attach all plugin objects in nsObjectFrame to some parent dom window event, then send event to window and all objects will handle it automatically
(Reporter)

Comment 5

9 years ago
Created attachment 405139 [details] [diff] [review]
Proposed fix, used in microb-engine for N900
Assignee: nobody → romaxa
Attachment #405139 - Flags: review?(roc)
Plugins in iframes won't hear about pluginsshow/pluginshide, right?

Another way the plugin can detect visibility is by tracking paints and invalidates. Suppose it periodically invalidates itself completely every few seconds. If it gets no paint event, then it must be completely invisible. If it gets a paint event, it is probably visible and should come out of its suspended state. Would that work? That wouldn't require any browser changes.
(Reporter)

Comment 7

9 years ago
Yes, we were considering this option in the beginning... I need to check with flash team again and recall why it was rejected.
(Reporter)

Comment 8

9 years ago
We had some problem with additional timeouts creation and internal flash implementation.

Theoretically it can be done:
NPP_InvalidateRect (create timer for 5 seconds)
..... (If timer created just continue.)
If timer finished and no Expose events came... then invoke suspend.

I will create new bug about this problem... and check how fast we can try this approach.
(Reporter)

Comment 9

9 years ago
Also with this new approach we should document it and make sure  that all plugins have implemented this functionality...

But most of plugins already handling VisibilityNotify signals (since windowed mode)... and with my patch it is very easy to port those plugins.
(Reporter)

Comment 10

9 years ago
Also question is why MacOSX port using this implementation and not rely all responsibility to plugins?
(In reply to comment #9)
> But most of plugins already handling VisibilityNotify signals (since windowed
> mode)... and with my patch it is very easy to port those plugins.

How many plugins really handle VisibilityNotify for this kind of optimization?

(In reply to comment #10)
> Also question is why MacOSX port using this implementation and not rely all
> responsibility to plugins?

I don't know, but we can't assume it's for this reason. They may need to know immediately when their window is hidden. Josh may know.
(Assignee)

Comment 12

9 years ago
> How many plugins really handle VisibilityNotify for this kind of optimization?

chicken and the egg.  right now, flash on the n900 device and diamondx.

Updated

9 years ago
Attachment #405139 - Flags: review?(joshmoz)
In comment #9 Oleg said
> But most of plugins already handling VisibilityNotify signals (since windowed
> mode)... and with my patch it is very easy to port those plugins.

If "most plugins" just means Flash on the N900, then this isn't a very compelling argument.
(Assignee)

Comment 14

9 years ago
roc/josh, what is needed here; what are the next steps?
It seems to me nothing is needed here, Flash can do this optimization itself as per comments #6 and #8.
(Assignee)

Comment 16

9 years ago
wontfix.  per #6 #8.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX

Updated

9 years ago
Attachment #405139 - Flags: review?(roc)
Attachment #405139 - Flags: review?(joshmoz)
(Assignee)

Comment 17

9 years ago
this is required to get invalidation events from the flash plugin on the maemo platform.  romaxa, can this be fixed on the plugin side before you ship?  If now, we will need something in the browser as right now we do not receive any invalidation events.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
(Assignee)

Comment 18

9 years ago
Created attachment 407933 [details] [diff] [review]
cleaned up patch -- minimum required.

assuming that flash can not be fixed, would this be acceptable?
Assignee: romaxa → doug.turner
Attachment #405139 - Attachment is obsolete: true
Attachment #407933 - Flags: review?(roc)
Comment on attachment 407933 [details] [diff] [review]
cleaned up patch -- minimum required.

This is pretty lame. It's not a very good visibility test --- it will report hidden tabs, scrolled out of view, etc, as visible --- but if it works for you, I can swallow it. Just promise me that Flash will get fixed and we can take this out.
Attachment #407933 - Flags: review?(roc) → review+
(Assignee)

Comment 20

9 years ago
I am also unhappy with the change and hope that the plugin can be fixed before they ship.
(Assignee)

Updated

8 years ago
Blocks: 524413
(Assignee)

Comment 21

8 years ago
http://hg.mozilla.org/mozilla-central/rev/d7b2ca236644
Status: REOPENED → RESOLVED
Last Resolved: 9 years ago8 years ago
Resolution: --- → FIXED
(Assignee)

Updated

8 years ago
Attachment #407933 - Flags: approval1.9.2?
Comment on attachment 407933 [details] [diff] [review]
cleaned up patch -- minimum required.

a192=beltzner
Attachment #407933 - Flags: approval1.9.2? → approval1.9.2+
(Assignee)

Comment 23

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/295544af3bda
status1.9.2: --- → beta1-fixed
You need to log in before you can comment on or make changes to this bug.