Plugins do not resize correctly in XUL

VERIFIED FIXED in mozilla0.9.2



18 years ago
17 years ago


(Reporter: kens, Assigned: peterlubczynski-bugs)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [seeking review])


(4 attachments)



18 years ago
To reproduce:

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

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 

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

18 years ago
Ever confirmed: true

Comment 2

18 years ago
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

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

Comment 4

18 years ago
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

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

18 years ago
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

18 years ago
Chris, here is another ObjectFrame width/height problem.
Assignee: av → karnaze

Comment 7

18 years ago

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

Comment 8

18 years ago
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

18 years ago
Created attachment 32801 [details] [diff] [review]
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

18 years ago

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

18 years ago
Created attachment 32804 [details] [diff] [review]
cleaned up, more readable -u5 patch

Comment 12

18 years ago
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"/>

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

18 years ago
Re-assing to myself.
Assignee: karnaze → peterlubczynski
Keywords: testcase
Priority: -- → P3
Target Milestone: --- → mozilla0.9.1


18 years ago
Keywords: testcase → patch

Comment 14

18 years ago
Marc, can I get a review if you have a chance?
Whiteboard: [seeking review]

Comment 15

18 years ago
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.
Summary: Plugins do not resize correctly → Plugins do not resize correctly in XUL
Created attachment 33341 [details] [diff] [review]
Patch to sample plugin to make the behaviour easier to see
Created attachment 33342 [details]
Test case demonstrating the problem
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

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

Comment 20

18 years ago
Moving to m0.9.2
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 21

18 years ago
Patch checked in, marking FIXED.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 22

18 years ago
marking VERIF based on reporter's email :

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

> Ken
You need to log in before you can comment on or make changes to this bug.