77234 - Plugins do not resize correctly in XUL

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[kens]

To reproduce:

1. Build and install the "testevents" plugin, which can be found in 
modules/plugin/testevents.

2. Run Mozilla.

3. Open SimpleEventsTest.html.
The testevents plugin contains a simple Gtk text widget, which is scaled to 
take up the entire allocation granted to its parent window, the plugin.
Type a large enough amount of text into the widget so that the text extends 
beyong the rightmost extent of the plugin window (i.e. out of the clipping 
region).

4. Increase the width of the Mozilla window. The widget resizes accordingly 
allowing you to see the text which was previously hidden off to the right.

5. Now decrease the width of the Mozilla window. The widget DOES NOT resize 
accordingly, but remains the same width as it was when the Mozilla window was 
larger -- part of the widget to the right of the plugin is now hidden.

It seems as though resizing ONLY takes place when one of the plugin's 
dimensions (i.e., width or height) grows larger than it has ever been before. 
This problem occurs with all plugins.

Comment 1

[Mark Hammond [:markh] [:mhammond]]

Confirming.

Comment 2

[kens]

The problem is even more simple than what I reported earlier:

1. If the plugin has width or height set to a percentage (i.e., width="100%), 
the width becomes that percentage of the width of the ENTIRE application 
window, rather than that percentage of the plugin's containing XUL frame.

2. flex doesn't work at all. The plugin remains a fixed minimum size forever 
and does not respond to resizing of its parent frame.

Comment 3

[Peter Lubczynski]

Can a testcase be attached? Is this on Linux only? Does the console spew 
anything out?

Comment 4

[kens]

The test case is in the tree in the modules/plugin/testevents directory.
It was mentioned in the original bug posting:

"1. Build and install the "testevents" plugin, which can be found in
modules/plugin/testevents."

Sorry if it wasn't clear.

There is a subtle difference between the problem on Linux and on Windows.
On Linux, embed objects contained within a box having the flex attribute
set do not scale, but rather remain at a default size (240x200 -- see
nsObjectFrame.cpp). On Windows, they do scale properly if the flex
attribute is set.

However, if the width and height attributes are set to a percentage value,
scaling is incorrect as described on both Windows and Linux.

Comment 5

[kens]

nsPluginInstanceOwner::GetContainingBlock() is suspect because it walks up the
layout tree looking for the nearest parent frame which is "percentage based."
If IsPercentageBase() is flawed, then we could end up walking too far up the
tree and picking a containing frame which has the wrong dimensions.

Comment 6

[Peter Lubczynski]

Chris, here is another ObjectFrame width/height problem.

Comment 7

[Peter Lubczynski]

Ken,

What kind of frame is the plugin in? What does 
containingFrame->IsPercentageBase() return?

Comment 8

[kens]

The plugin is inside an nsFrame. If I set the "display: block" style attribute 
of the plugin's containing box, then IsPercentageBase() stops at the plugin's 
containing box, which is in that case an nsBlockFrame. 
nsBlockFrame::IsPercentageBase() always returns PR_TRUE. I think I'm close...

Comment 9

[kens]

Attachment: Fixes a logic error in nsObjectFrame::GetDesiredSize() which was causing object frames to resize to a default size even when it is inappropriate to do so.

Comment 10

[Peter Lubczynski]

Ken,

Looks like you included some extra code in your patch. I'll attach a more 
re-able one. Will this patch in conbination with intilizing max-element-size fix 
the resizing on Linux?

Comment 11

[Peter Lubczynski]

Attachment: cleaned up, more readable -u5 patch

Comment 12

[kens]

This patch fixes flex resizing in Linux. e.g., if your XUL looks like this:

<box flex="1">
  <html:embed type="application/x-scimoz-plugin"/>
</box>

it will now resize correctly (before it maintained a fixed, default size).

The patch does not fix resizing if your XUL specifies percentage-based widths 
and heights. e.g.,

<html:embed width="100%" height="100%" type="application/x-scimoz-plugin"/>

Comment 13

[Peter Lubczynski]

Re-assing to myself.

Comment 14

[Peter Lubczynski]

Marc, can I get a review if you have a chance?

Comment 15

[Peter Lubczynski]

Peter T:

Do you know anyone in XUL QA who can whip up a quick testcase out of the code 
mentioned above. I don't know anything about XUL.

Comment 16

[Mark Hammond [:markh] [:mhammond]]

Attachment: Patch to sample plugin to make the behaviour easier to see

Comment 17

[Mark Hammond [:markh] [:mhammond]]

Attachment: Test case demonstrating the problem

Comment 18

[Mark Hammond [:markh] [:mhammond]]

I just attached 2 files.  The first is a patch to the sample plugin, so that 
the text it draws is always centered in it's window.  This is not strictly 
necessary to see the bad behaviour, but helps a little.

The second one is a chrome XUL file that demonstrates the problem.  Resizing 
the window causes all sorts of flicking and weird sizing.  Once the window has 
grown to a certain size, none of the children window can be sized smaller.

If you remove the "width=100%" from the html:embed element, then it behaves a 
little better, but there is still lots of flicking when resizing, and the 
plugin window can not shrink beyond the default plugin size.

Applying the proposed patch makes this test case size as smoothly as a baby's 
butt :)

Comment 19

[Marc Attinasi]

sr=attinasi based on the comments of kens and Mark, and the code in patch 32804.

Comment 20

[karnaze (gone)]

Moving to m0.9.2

Comment 21

[Peter Lubczynski]

Patch checked in, marking FIXED.

Comment 22

[shrirang khanzode]

marking VERIF based on reporter's email :

>I know for sure. It works in a build I built this afternoon, pulled from
> CVS.

>TTUL
> Ken