155248 - [viewpoint] browser stops responding (UI and desktop do not respond to mouse clicks) after loading viewpoint ad

Status: VERIFIED INVALID

(Plugins Graveyard :: Viewpoint Media Player, defect, P2)

Description

[shrirang khanzode]

launch 0701 brnch build with viewpoint plugin.

open a url in the first tab : home.netscape.com

In another tab launch this url : 
http://cole.viewpoint.com/~compuserve/ads/durango/index.html

Now while the Dodge ad is loading, try clicking in url bar..or try to change 
tabs...you cannot do so unless you overlap the browser window with some other 
application ( alt +tab).
Peter, is this related to the acrobat freeze problem ? Thx!

Comment 1

[Peter Lubczynski]

Hm...sounds like you could be seeing bug 82534 or bug 131007. Does right click
also help?

--->reassign to av

Comment 2

[shrirang khanzode]

nope, right click does not help

Comment 3

[Peter Lubczynski]

Hm...in switching tabs I could even get viewpoint to paint in the wrong tab
before hanging. In all cases a quick alt+tab fixes it but to the end user it
will look like the app hung.

It looks like we call NPP_SetWindow when the tab is made visible, but not when
leaving that tab and I bet the plugin doesn't know the tab has been made
invisible. We should probably be clearing the clip or something like we do on
Mac. However, I'm not sure of how to get notified of a tab switch on
Windows?????  (on Mac, we check widget and view visiblity off the idle event timer)

Comment 4

[rubydoo123]

The plug-ins triage team (av, beppe, peterl, serge and shrir) have reviewed 
this issue and have made the following determination:

This will be addressed in the next milestone

Comment 5

[Peter Lubczynski]

This may be similar to bug 116766, but this is a windowless plugin.

Comment 6

[av (gone)]

This happens in separate window too, not only in tabs. The whole desktop area
does not respond to the mouse click, although you can successfully click on the
Windows taskbar. Click on the taskbar unfreezes everything.

Comment 7

[av (gone)]

Ari, 

on this ad -- should the car go beyond the plugin area? The things are
different: if you just load the page the car moves across the plugin area, then
across the browser window and the even crosses the desktop. But if you activate
some other window _before_ the plugin fully loads, then Dodge does not go beyond
the plugin area. 

Which behaviour is expected? Is not this what viewpoint engineers might want to
look at? It looks like the plugin captures mouse input from any point on the
desktop and does not release it.

Comment 8

[Ari Berger]

I'll take a look at the content, and see what is supposed to be happening.

Comment 9

[ales]

This behavior is actually correct and content controllable. The reason we 
promote this behavior is that the hyperview is a modal experience. The reason 
hyperview goes away if there is a change of focus, is to make sure the user does 
not feel the machine locked up on him/her. The hyperview will get always 
suppressed if the user alt tabs, clicks on
the task bar or some other window gets activated. You can suppress any of these 
evens in content (not recommended) or add additional user interactions (clicks 
and keys down and such)
So the behavior you see in the case of this add is correct.

Comment 10

[rubydoo123]

Great! Since this is by design, then I am marking this as a WFM.

Comment 11

[Peter Lubczynski]

But that's exactly what I'm seeing when reproducing this bug -- Netscape feels
like it has "locked up". I see the ad go around the screen but clicking in the
browser window doesn't do anything. In fact, it doesn't do anything after the ad
has finished and the window is unusable. Also, if I scroll right away, there is
some weird painting going on. I was also seeing Viewpoint paint in the wrong tab
[then lock up] when switching between them. I've found the lock up happens even
without tabs but alt+tab release it every time. 

Comment 12

[av (gone)]

>But that's exactly what I'm seeing when reproducing this bug -- Netscape feels
>like it has "locked up".

As far as I understood from comment #9 this is desired behaviour. Plugin is
designed such a way that content can do this on purpose. Why should we 'fix' it?

Comment 13

[Peter Lubczynski]

--->INVALID

I talked with Ales on the phone and he explained that this is a bug in the
content of this testcase. Viewpoint has the ability to control how the user can
regain control and this content seems to be broken.

Comment 14

[shrirang khanzode]

closing as verif , then