Closed Bug 794836 Opened 12 years ago Closed 11 years ago

Firefox stretches Flash content while resizing browser window

Categories

(Core Graveyard :: Plug-ins, defect)

15 Branch
x86_64
Windows 7
defect
Not set
normal

Tracking

(firefox15 affected, firefox16-, firefox17-, firefox18-)

RESOLVED WONTFIX
Tracking Status
firefox15 --- affected
firefox16 - ---
firefox17 - ---
firefox18 - ---

People

(Reporter: sadigov, Unassigned)

References

Details

(Keywords: regression, testcase)

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20100101 Firefox/15.0.1
Build ID: 20120905151427

Steps to reproduce:

1. Create an Flex application with height and width set to 100%.
2. Set "wmode" parameter to "transparent" for it, while embeding to HTML.
3. Try to resize browser window fast.

Flash player version: 11.4.402.265.


Actual results:

When window is resized, flash content appears to be stretched. For example you browser window height is 100px, so flash displays its content for 100px as well. Then you are resizing browser window quickly to 700px. As result, for some short moment of time flash content which is displayed for 100px remains and is stretched to 700px. After that flash displays content for 700px normally.

Similar issue can be seen if browser window size is reduced during the resize. But in this case larger flash than browser window size content will be squeezed.


Expected results:

It looks like performance degradation for processing flash content resizing, in case if "wmode" is set to "transparent" or "opaque".

Firefox should resize flash content smoothly as in previous versions, doesn't matter what value is set for "wmode" parameter.
Severity: normal → minor
Priority: -- → P3
Can you please provide a small testcase ?

>Firefox should resize flash content smoothly as in previous versions, doesn't matter 
>what value is set for "wmode" parameter.

Are you sure that this is caused by a change in Firefox? 
The newer flash player versions are coming with a "Protected mode for Firefox" that caused all kinds of issues. Is it possible that a flash player update triggered this ?
Yes, I'm sure that problem is related to new version of Firefox. I was trying to reproduced with old versions of FF, but couldn't.

I've just downgraded my FF to closest prior version of current one (to 14.0.1) and it can't be reproduced as well. So this is definitely problem with current version of Firefox.
Add a testcase (like SWF file or HTML page) if possible, please .
Here is overview of issue and how it can be reproduced. I'm going to attach source in few minutes.
Please find SWF file and HTML for reproducing issue. This is release from Flash Builder. If it can't be loaded locally, please try to add its local path to flash player security settings (http://www.macromedia.com/support/documentation/en/flashplayer/help/settings_manager04.html)
Thanks, the testcase bin-release/ResizeTest.html works perfectly. It looks like a regression since Firefox 15. Before the regression, there is no stretching of content during the windows is being resized.

Mozregression range:

m-c
good=2012-05-30
bad=2012-05-31
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=65fa5cb6f79c&tochange=3aa566994890

m-i
good=2012-05-29
bad=2012-05-30
http://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=ce3d4fd7033b&tochange=8f8639307984

I would say the suspected bug is:
Bas Schouten — Bug 758432: Fix SetScaleToSize call for plugins. r=roc
Blocks: 758432
Severity: minor → normal
Status: UNCONFIRMED → NEW
Component: Untriaged → Plug-ins
Ever confirmed: true
Keywords: regression, testcase
Priority: P3 → --
Product: Firefox → Core
This is not a critical issue for release, but we'd consider taking an uplift to Aurora once fixed.

(In reply to Loic from comment #7)
> I would say the suspected bug is:
> Bas Schouten — Bug 758432: Fix SetScaleToSize call for plugins. r=roc

This sounds right.
Any updates on this?
This is the intended behavior. In order not to block the browser resize on the Flash process which is sometimes very slow, we paint Flash asynchronously. While waiting for Flash to paint at the new size, we resize the old content.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
This should not be the intended behavior. It has never been the way browsers in the past displayed 100% width/height adjusted Flash. It breaks a great many Flash games and programs that rely on knowing the size of the viewport to position items. The browser is supposed to wait for Flash to paint, just like it waits for every other element in the DOM to paint. Imagine how ugly it would be if all DOM elements and all text in the window stretched until you stopped resizing the window.

The browser doesn't halt javascript execution or canvas redraws for multiple ticks during resize events. It is not the browser's business to do that for Flash. If a site is running slowly and it's got full screen flash going on, it is obvious and expected that resizing the window may be a little slow. The same is true for Javascript animated content, which executes slower than AS3, so why the anti-Flash bias?

Most halfway decent Flash applications are built with liquid layouts that listen for resizes and handle them in custom ways. This is why there is more than one scale mode available on the Flash stage. There are literally NO major flash applications, games or websites that set Flash's width to 100% and use a STRETCH scalemode. And yet that is what you are unilaterally imposing on every single Flash site. It looks terrible.

This is particularly bad for sites in which the Flash needs to resize its own height via javascript. As soon as it alters the browser window size, the content becomes a stretching bitmap of itself prior to snapping back. In that case the only workaround now is to make an extremely tall flash movie and mask it off in a div with overflow:hidden.

Please take a look at http://vickmanassociates.com for example, which has a liquid layout, and what happens when you resize the window's width. It's clear what is supposed to happen, the column is resized and the photo is resized. You are intentionally covering that up with a bitmap taken when the dragging starts, which doesn't even antialias as it's resized.

Listen, people built Flash sites because they were trying to do things that were beautiful and couldn't be done in the DOM. You have no right to just break them all.
"While waiting for Flash to paint at the new size, we resize the old content."???

This is like saying that while you wait for this textarea to redraw, you zoom the text, scaling font size!!!

Can you even imagine the *ugliness* of this?

Intended behavior? For who?

If you can't wait for Flash to draw, don't draw. Everyone can live with a flicker waiting for a redraw, but seeing your font or a small icon resized by 1500% can't be considered "Intended behavior".

Scaling a whole interface by zooming it is foolish, and ugly, and frankly shows no understanding of how a plugin works. You are giving for granted that plugin content is a banner or an image-like thing, while it may be text, menus, a whole application. You hate Flash and may even be right, but a plugin may be anything else!!!

You are killing websites that worked on Netscape 4.7 year 2001, but if that's ok for you (thanks..), you are actually killing any future plugin ideas other than a resizable image-like banner kind of thing.

If we didn't have plugins working fine we wouldn't have had Flash, we wouldn't have had things like youtube, probably nobody would have really cared to standardize for an HTML5 video tag or many other things like streaming, or the Canvas. Can you see the trend? Most of the advancement in HTML5 are just cloning of internal plugin functionalities. Someone in the future may invent something you can't imagine, and write a plugin for it, then it will have to face your "we resize the old content" "intended behavior".
You are sacrificing the future to a war against one single plugin.

Please stand back, revert your WONTFIX to something more reasonable like MAYBEFIXEDBYJUSTREVERTINGTO2004 and leave this kind of decisions to someone else that has an understanding of the plugin workings and philosophy.
These (old) websites resize a DIV vertically to accomodate Flash content.

http://www.marcolecchi.it/

http://www.fimagency.eu/#/a_it_home

As you will see, the resizing is really ugly and unwanted. The whole interface moves like a plastic bubble bouncing, making the websites unusable, while it should just stand still because there is no reason for it to move.

Enlarging a DIV scales its content? Bah.
BTW in case you think this is just a complaint by those of us who specialize in full-screen "art" Flash sites, _check out what happens when you resize the window while you're looking at Google Street View_ which is, of course, Flash in a resizable DIV. Does that look like the expected behavior?
It is an essential performance behavior that we paint Flash content asynchronously. That means we have to do *something* while the window is resizing. If you would like to suggest an alternate painting algorithm and a way that we could test it against our current stretch algorithm, I'd be willing to entertain reopening this. But otherwise there's nothing to track here.

Possible alternatives that we rejected for various reasons:
* paint at the original size
** for transparent flash, make the extra size transparent
** for opaque flash, make the extra size grey, or white, or the CSS background color, or a checkerboard
** Considered both topleft and center-extending this.
* Pixel-extend the bottom of the existing bits

None of these seem to be any better than the current scaling solution.
Of course extending the edge bits would make no sense at all -- but neither does unconstrained scaling of a bitmap snapshot of the plugin. Putting gray, white, or transparent pixels would be far preferable to what it's doing now, because most Flash apps which go 100% width do not want to stretch in an unconstrained way when the window is resized. So at the end of the resize, now, we're looking at a stretched version that then "snaps" to what Flash wants to render. 

But the bigger issue seems to be that FF is not letting Flash render on every frame, or even for several frames after a resize. Supposedly because blocking for Flash could cause slow behavior with complicated Flash sites...? But I notice when I try resizing a site that's running heavy JS with Canvas that the resize blocks for the canvas redraw (which takes a lot longer than most modern flash redraws). Canvas is considered an embedded content tag under the w3 spec just like an object or embed tag is.

The correct behavior, which ironically IE still has, is:
1. resize window
2. paint background color
3. block for plugin or canvas rendering
4. repeat
We are absolutely not going to block on plugin rendering.
Can I ask then:

1. When was the decision taken to block plugin rendering for multiple frames during resize, and who made this decision? Because this is new in the history of browsers. Note again this breaks google street view, which was developed with resizing in mind.

2. Why is it necessary to block _multiple plugin frames_ from rendering if the computer has the power to render them, and what is the cutoff point -- i.e. how much extra time is the browser now waiting after any given change in container size before it allows the plugin to render? It seems to be waiting quite awhile (and tabbed content seems to wait now until the tab is clicked, showing an ugly stretched version of the content before rendering).

3. Why don't you block for canvas renders? E.g. set a bunch of filters on this and resize the window:
http://joshstrike.com/strikedisplay/Demo/filterTest.html
that's just javascript and canvas. Of course it's much less smooth to resize than a piece of Flash rendering the same exact thing, but in this case we're not even resizing the canvas itself _and you are blocking for it_.

Naturally you are, because that's the expected behavior and that is how browsers have always worked.

Basically you are breaking a huge amount of very hard work, careful work on thousands of websites that do not scale or stretch in the way you are forcing them to, and moreover it looks like the browser or site is about to crash when people see these bizarre flashes of things scaling up and down and weirdly across the screen. In other words you are making thousands of hours of other people's work stop working the way it's intended to. For no discernible reason other than it being in Flash rather than on canvas.
ANY of those is better than zooming 1350% existing content!!

[Except maybe pixel-extend, looks like a broken Win98.. seriously]

* paint at the original size is certainly better: as long as nothing changes it is percieved as a "lag", not an error.

1) you must take into account the centering (vertical and horizontal), not the one in the DIV but the Flash one
   The one defined in: <param name="salign" value="rb" />

2) for transparent flash, make the extra size transparent

3) for opaque flash, make the extra size the color of the Flash background (NOT HTML but Flash object tag background)
   The one in: <param name="bgcolor" value="#ff9900" />

This is the way to do it. Almost. Unless you also want to look at the <param name="scale" value="..." /> in which case you have many more funky options like "noborder". And that would be really "correct". I can describe all the modes, if someone needs it.

The bad thing is that it is something specific to Flash, so it will harm other plugins in a bad way anyway, unless they specify the same parameters respecting Flash syntax or you setup a standard way to ask the plugin for the correct behavior. The not so bad thing is that it is effortless for a plugin designer to respect 2 similar parameters in the future.

Anyway, even if you fix it for Flash, this behavior is still broken. The logic is broken. *You must not assume you know things about the contents of a plugin*. It is not the way to do it.

I would like to see how much this "essential performance behavior" gained in the real world, as even on websites that ran fine and smoothly in the years of the modem, this "performance behavior" actually slows down repainting a *lot*.

Such "performance" was not essential when the plugins were born in the nineties, otherwise there would be a way to handle it correctly. Was not considered essential later on, when computers were single core pentiums struggling to handle a web page, and sincerely it became essential only when Apple found they had some commercial problems with Flash, so it appeared in Safari first, then all the others that had to compete on the milliseconds on cold benchmarks falled in.

Maybe we should redefine the term "essential".
What a disappointing regress of FireFox plugin handling. I can confirm that numerous Flash websites of mine have been maimed by this engineering mis-judgement. 

The explanation given on this bug puzzles me. Not only is this blanket redraw degradation justified because of a "sometimes slow" process (to which the solution would be an ADAPTIVE degradation routine!), but it's suspicious because this wasn't a problem in the past. Did the FF team actually examine any use-cases? It seems like it didn't.

Secondly, what is with the bizarre assumption of how the plugin content should be redrawn while resizing? Stretching the current bitmap?? That sounds like a joke on how NOT to handle it. I cannot think of a single time I used Flash where that would be a desirable effect. Even if I had to wait a horribly long time to redraw (which I shouldn't) then the obvious in-between state would the last drawing clipped to the current view rectangle. 

But lastly, why does the plugin get throttled on resize when stuff like Canvas does not? It makes no sense.

It's hard enough having to entrust the behavior of my content to browser vendors, misjudgements like this don't re-assure me.

Good luck to all the engineers at Mozilla, you do great work -- this decision is just wrong. Cheers.

-Aaron
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.