Justin Dolske [:Dolske] Reporter
	Description • 14 years ago

Bug 59314 is implementing tab-modal prompts, as part of that bug 596371 modified the browser's UI so that each <browser> is now inside a <stack> -- making it easy for the tab-modal prompts to overlay content by just sticking some XUL into the <stack>.

I think this is working fine on OS X (will retest to be sure), but on Windows I'm seeing Flash on top of the tab-modal UI that's overlaying the rest of the page. It's not just painting on top, it's also responding to mouse movement / clicks as if the stack child over it wasn't there at all.

Screenshot attached; the gray striped background is part of the tab-modal prompt.

	Justin Dolske [:Dolske] Reporter
	Comment 1 • 14 years ago

Yep, works as expected on OS X.

	Benjamin Smedberg
	Comment 2 • 14 years ago

Presumably this is windowed plugins only. I thought roc told me that we masked out the plugin widget, but I didn't remember seeing any code to do that.

	Timothy Nikkel (:tnikkel)
	Comment 3 • 14 years ago

I don't think we can paint any translucent over plugin widgets. If something opaque is over the widget we clip that out of the plugin widget. Perhaps we need to hide the plugin widget completely?

	Timothy Nikkel (:tnikkel)
	Comment 4 • 14 years ago

Opera manages to handle this case correctly. I wonder how they do it.

	Timothy Nikkel (:tnikkel)
	Comment 5 • 14 years ago

Opera has a "Hidden Plugin Container" that is usually empty, but get populated when a modal dialog is active on the page.

	Justin Dolske [:Dolske] Reporter
	Comment 6 • 14 years ago

(In reply to comment #3)
> I don't think we can paint any translucent over plugin widgets. If something
> opaque is over the widget we clip that out of the plugin widget. Perhaps we
> need to hide the plugin widget completely?

I'd be ok with that for the purposes of tab-modal prompts; the primary problem here is that the plugin escapes the <stack> (ie, can be interacted with). A blank box in the correct place would be acceptable, although a bit less sexy to demo. ;-)

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 7 • 14 years ago

We need to modify the code that computes the clip region for the plugin window. Currently it clips out the area of any opaque display items covering the plugin. In this case, I guess that isn't helping you since your dialog background is clipped to rounded corners so is not opaque over its rectangle.

One option would be to clip out the rectangles of any chrome content that overlay the plugin, even if they're not opaque. The corners would look a little bit odd though since the plugin would not appear in the area that's inside the bounding rectangle of the chrome content, but outside the rounded corner.

Another option would be to just use non-rounded corners for the alerts.

Another option would be to build a complex region that follows the rounded corner precisely (except we won't be able to antialias it).

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 8 • 14 years ago

(In reply to comment #7)
> One option would be to clip out the rectangles of any chrome content that
> overlay the plugin, even if they're not opaque. The corners would look a little
> bit odd though since the plugin would not appear in the area that's inside the
> bounding rectangle of the chrome content, but outside the rounded corner.

Oops, actually since you're putting a translucent chrome overlay over the whole content window, this option would just make the plugin disappear completely. Is that OK? We actually know of no reliable way to capture the contents of a windowed plugin in a way that would let us display translucent content over it.

	Justin Dolske [:Dolske] Reporter
	Comment 9 • 14 years ago

(In reply to comment #8)

> Oops, actually since you're putting a translucent chrome overlay over the whole
> content window, this option would just make the plugin disappear completely. Is
> that OK?

Yes, I think that's fine so far as tab-modal prompts go, though. It's neat to watch a Flash video play under the prompt's overlay, but not critical functionality. [Does this limitation also mean it wouldn't be possible to replace the plugin with a static image of it's last contents before the prompt? That might be an interesting workaround...]

I suppose this means if someone's using the <stack> for something else, as soon as a translucent element overlaps any bit of a plugin, it would disappear entirely?

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 10 • 14 years ago

(In reply to comment #9)
> Yes, I think that's fine so far as tab-modal prompts go, though. It's neat to
> watch a Flash video play under the prompt's overlay, but not critical
> functionality. [Does this limitation also mean it wouldn't be possible to
> replace the plugin with a static image of it's last contents before the prompt?
> That might be an interesting workaround...]

It's kinda-doable but it's ugly and risky.

> I suppose this means if someone's using the <stack> for something else, as soon
> as a translucent element overlaps any bit of a plugin, it would disappear
> entirely?

The bounding box of the translucent element would be cut out of the plugin. Is that too ugly? It's actually probably OK if the element is rectangular. We could make the plugin disappear completely if any chrome element is over any of it, if that sounds better.

	Justin Dolske [:Dolske] Reporter
	Comment 11 • 14 years ago

(In reply to comment #10)

> The bounding box of the translucent element would be cut out of the plugin. Is
> that too ugly?

Ugly, but seems acceptable given the alternatives. :) Hiding the whole element would be acceptable for my case (since I overlap the whole thing!), but I can see how developers could get confused/annoyed if the whole plugin "disappears" when something overlaps it by a pixel or two.

	Benjamin Smedberg
	Comment 12 • 14 years ago

Why was this nominated and marked blocking? tab-modal prompts are not a Firefox 4 feature, and so I'm not sure why we need to fix this now.

	Josh Aas
	Comment 13 • 14 years ago

I thought that tab-modal prompts were a Firefox 4 feature, that is why I marked this blocking.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 14 • 14 years ago

This fixes it. There are a few things going on:
-- Generalize mIsForEventDelivery to a Mode value in nsDisplayListBuilder. The Mode encodes what the builder is being used for --- painting, event delivery, plugin region calculation, or something else.
-- In plugin region calculation, treat all chrome display items as opaque. This ensures plugins are clipped away even under translucent chrome content.
-- A plugin whose widget clip region does not match what we expect from the paint display list is treated as non-opaque. This happens when the previous step has caused some plugin content to be clipped away. We need the content under the plugin to be painted in that case.
-- Adding operator!= to nsTArray. This is trivial so I think anyone can review it.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 15 • 14 years ago

Note, the patches in bug bug 593839 are needed to make the area under the translucent chrome element render correctly with accelerated layers. Without those patches, nsObjectFrame::PaintPlugin tries to render plugin content to the destination context using PrintWindow or some other method. This is a bad idea (we should probably just remove that code).

	Timothy Nikkel (:tnikkel)
	Comment 16 • 14 years ago

Comment on attachment 482813 [details] [diff] [review]
fix

>+TreatAsOpaque(nsDisplayItem* aItem, nsDisplayListBuilder* aBuilder)
>+  if (aBuilder->IsForPluginGeometry()) {
>+	// Treat all chrome items as opaque
>+	nsIFrame* f = aItem->GetUnderlyingFrame();
>+	if (f && f->PresContext()->IsChrome())
>+      return PR_TRUE;

Fix the indent here.

That was less invasive than I had imagined.

	Nochum Sossonko [:Natch]
	Comment 17 • 14 years ago

Comment on attachment 482813 [details] [diff] [review]
fix

This doesn't apply anymore.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 18 • 14 years ago

Updated to trunk.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 19 • 14 years ago

The test here timed out on Mac try:
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1288963124.1288966147.15906.gz
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1288967556.1288968934.26679.gz
http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1288967621.1288968962.26875.gz
I need to look into that before landing.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 20 • 14 years ago

Ah, I just need to add 'todo' to the 'imports' list.

	Robert O'Callahan (:roc) (email my personal email if necessary) Assignee
	Comment 21 • 14 years ago

http://hg.mozilla.org/mozilla-central/rev/d01932e9114e