425954 - HTML <embed> does not do intrinsic sizing until it's zoomed

Status: RESOLVED FIXED

(Core :: SVG, defect)

Description

[Duncan Loveday]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032805 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008032805 Minefield/3.0pre

Using ctrl + or ctrl - with this attachment https://bugzilla.mozilla.org/attachment.cgi?id=312374 from bug 425662 causes the image to zoom to a much larger scale than that at which it is initially drawn.

Reproducible: Always

Steps to Reproduce:
1. Load the attached file
2. Press CTRL+ or CTRL-
3. Note the change in scale of the image
4. Now reload the page (e.g. press CTRL-R)
Actual Results:  
In step 3 the image becomes very large instead of changing scale by a small amount.
In step 4 the image returns to exactly the scale it was initially drawn at.

Expected Results:  
In step 3 a small change in scale should be seen.
In step 4 the image should be re-displayed at the same scale as what was seen after step 3, i.e. the slightly-changed initial scale, not return to the original scale.

If you press ctrl + twice and then reload then the image is shown a little bigger than on first rendering.

Comment 1

[Duncan Loveday]

Sorry - the comment about returning to the same scale in step 4 is wrong. The image does gradually get bigger with each cycle of CTRL +, CTRL R.

The only issue is the sudden jump in scale when pressing CTRL +, CTRL - or CTRL 0.

Comment 2

[Duncan Loveday]

(In reply to bug 425826 comment #4)
> 
> I suspect that is a bug. Is it connected to the dynamic assignment of a
> viewBox?
> 
No I don't think it is. I've tried adding the viewBox attribute to the SVG source (<svg onload="top.loadSVG(evt);" width="4000" height="1000" viewBox="0 0 10000 10000" version="1.1" xmlns="http://www.w3.org/2000/svg">) and also removing it altogether and I get the same effect all the time.

Comment 3

[Duncan Loveday]

Attachment: SVG test case

Here's a much simpler test case. The issue is nothing to do with the viewbox. The behaviour is observed whenever an <EMBED> does not have an explicit width and height and contains an SVG that does have width and height. When first rendered the EMBED has fairly small height and width, a couple of hundred pixels. As soon as you use page zoom the embed expands to the size of the SVG in the embed. If the SVG has a viewbox then that causes a change in scaling. If the SVG doesn't have a viewbox then a previously-truncated SVG is suddenly seen in full.

Just wondering whether it'd make more sense if the embed was initially rendered at a size determined by the contents. That's what seems to happen when using OBJECT rather than EMBED. I suppose it's difficult to argue what's correct as EMBED isn't part of the proper HTML standards.

Comment 4

[Duncan Loveday]

Attachment: HTML test case

Comment 5

[Duncan Loveday]

Regression between

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/11/2007-11-17-05-trunk/firefox-3.0b2pre.en-US.win32.installer.exe

and

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2007/11/2007-11-18-05-trunk/firefox-3.0b2pre.en-US.win32.installer.exe

FF2 has the embed with scrollbars.

Comment 6

[Duncan Loveday]

I also notice the embed get progressively truncated as one zooms out. That might be a separate bug though.

Comment 7

[Duncan Loveday]

(In reply to comment #6)
> I also notice the embed get progressively truncated as one zooms out. That
> might be a separate bug though.
> 
The truncation on zoom out is fixed in the current trunk. I should have checked before commenting.

Comment 8

[Jonathan Watt [:jwatt]]

So <embed> should size in the same way as <object>. The only bug seems to be that an <embed> without a specified width and height is not using the size of the SVG that it is embedding - at least not unless you zoom it.

Comment 9

[Duncan Loveday]

(In reply to comment #8)
> So <embed> should size in the same way as <object>.

Arguably, yes.

> The only bug seems to be
> that an <embed> without a specified width and height is not using the size of
> the SVG that it is embedding
> 

Yes. An EMBED with a specified width and height is fine AFAIK. Consequently I don't think this bug is all that serious, especially given the lack of any concrete standards for EMBED.

Comment 10

[Jonathan Watt [:jwatt]]

The change in behavior was caused by the fix for bug 294086 BTW, which landed 2007-11-18.

Comment 11

[Duncan Loveday]

Just a thought - with FF2, EMBED and OBJECT without explicit size behave the same - occupy a fixed amount of screen and have scrollbars to accommodate larger content.

If you make FF3 EMBED the same as OBJECT then that'll make the zoom behaviour for EMBED more sane and be a good thing from a consistency point of view. BUT it will mean both differ from FF2. Not sure how much of a concern that is.

Comment 12

[Jonathan Watt [:jwatt]]

HTML <embed> is considered to be a "replaced element" in CSS terminology. As such, it should use the intrinsic size of the SVG it is embedding just like <object>. The behavior in FF2 where <object>/<embed> fall back to 300 x 150 px without using the intrinsic size of the embedded content (when available) is a bug. The 300 x 150 px is not really useful, so I don't expect this to be too much of a problem, and there's a lot of value in using the intrinsic dimensions.

Comment 13

[Duncan Loveday]

Sounds reasonable.

FWIW, IE6 and 7 with ASV truncate the SVG to a fixed, small size when using OBJECT or EMBED.
Opera doesn't "do" EMBED but OBJECT in version 9.27 does something similar to FF2 (small area with scrollbars)....until you refresh the page when it changes to the full area without scrollbars (like the current FF3 trunk with OBJECT).

Comment 14

[Jonathan Watt [:jwatt]]

Yeah, IE6/7 aren't exactly renowned for their standards compliance. ;-) As for Opera, that's clearly a bug you should report to them.

Comment 15

[Duncan Loveday]

This seems to have been fixed - resolve as WFM unless anyone else can still reproduce ?

Comment 16

[Jonathan Watt [:jwatt]]

Ah, excellent. :-) I'd like to figure out exactly what fixed it before closing this bug though, so please leave it open for now.

Comment 17

[Duncan Loveday]

It's fixed in the build below, so must be something that landed between 20080406 and 20080503

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008050306 Minefield/3.0pre

Comment 18

[Duncan Loveday]

Possibly bug 334227 as the test case has a <P> in it ?

Comment 19

[Duncan Loveday]

(In reply to comment #18)
> Possibly bug 334227 as the test case has a <P> in it ?
> 
No, it can't be that as the checking time is not in the range.

The behaviour changed in the nightly of 20080411 and then again on 20080501. 

Before 20080411 the symptoms I reported in this bug can be reproduced - initially the SVG is truncated in a small area of screen but is seen in full as soon as zoom is used. No scrollbars are present.

Between 20080411 and 20080430 inclusive, the embed is initially drawn at a similar size but has scroll bars instead of being truncated. As soon as zoom is used it gets much bigger and depending on the zoom level there may or may not still be a scrollbar. As you zoom in and out the scrollbars appear and disappear.

From 20080501 the SVG is seen in full both on initial pageload and when zoom is used and there are no scrollbars.

Comment 20

[Duncan Loveday]

Oops - got that first date wrong by a day. The dates when the behaviour changed are 20080410 and 20080501.

Comment 21

[Jonathan Watt [:jwatt]]

Thanks Duncan. So it was the fix for bug 431280 that fixed this. What's curious is that <object> has been unaffected, while <embed> was.

Comment 22

[Jonathan Watt [:jwatt]]

It's because nsHTMLSharedObjectElement::GetCapabilities (used for <embed>) sets the eOverrideServerType bit, but nsObjectLoadingContent::GetCapabilities (used for <object>) does not. Hence for <object> we could not fall into the |if| block changed by bug 431280.

Comment 23

[Duncan Loveday]

I'll take your word for it that this explains why the patch for bug 431280 resolved this bug.

Is it worth investigating what changed the behaviour in the nightly of 20080411 ? It was pretty strange from then until bug 431280 landed - scrollbars appearing and disappearing as one zoomed in and out. Still, it seems to be OK now which is the important thing.

Comment 24

[Boris Zbarsky [:bzbarsky]]

It bothers me that bug 431280 "fixed" this.  It really shouldn't have...

Duncan, I assume your about:plugins doesn't list a plugin for the SVG MIME type?

Comment 25

[Duncan Loveday]

No, definitely not although I do have the Adobe and Remesis plugins installed.

I actually think the behaviour has changed a few times - you can see the change easily on the two dates I mention but I think there are more subtle changes in between the two dates. For example, if you compare a build from 20080410 and a build from 20080430 they are close but the scrollbars don't appear and disappear at exactly the same points. In fact, on the later build they don't appear when zooming out, only when zooming in whereas the earlier build has them appearing in both zoom in and zoom out.

Comment 26

[Boris Zbarsky [:bzbarsky]]

So the plugins are installed but Firefox doesn't know about them, basically?

It sounds like there is some sort of weird timing dependence here...  Jonathan, how do we handle updating the size of the <embed> when the size of the <svg> inside it changes?

Comment 27

[Duncan Loveday]

Yes, I use the plugins with IE but not with Firefox.

Personally I'd be surprised if there is timing dependence because everything I see is completely repeatable.

Just been checking the builds mentioned in comment #25 once again - the behaviour is really quite different. On the 20080410 build the appearance or non-appearance of the scrollbars seems to be a function of the scale. At certain scales they appear and at others they don't. On the 20080430 build it's as if scrollbars are only shown when the scale passes the "high water mark". As you zoom in, scrollbars appear - zoom out and they disappear - zoom back in again and they don't reappear until you go beyond the highest level of zoom since the last page load.

Haven't identified when that change occurred or whether there are other variations.

Comment 28

[Jonathan Watt [:jwatt]]

Boris: I don't have any plugins, and it is 100% reproducible for me too.

The embedding frame is reflowed when the embedded SVG changes size (which it doesn't in the testcase) by the code here:

http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/layout/svg/base/src/nsSVGOuterSVGFrame.cpp&rev=1.134&mark=503,504#501

Comment 29

[Boris Zbarsky [:bzbarsky]]

Ah.  See, I think what might have been happening is that the <embed> frame was created and reflowed before the inner document even started being parsed.  The code pointed to in comment 28 wouldn't hadle that case, would it?  We'd need to trigger reflow of the embedding frame on Init() of the embedded SVG or something, I would think.

Not having the plugins just means that the change in bug 431280 changes when the frame gets constructed.  Instead of being constructed immediately, it's constructed once we have the subframe data.  At that point, by the time we do the reflow we know the final size.

Put another way, what happens if you script the document in the <embed>, remove the old <svg> element, and put in a new one with a different size?  I'd think the <embed> should resize, and it doesn't look like it would with the current code.

Comment 30

[Jonathan Watt [:jwatt]]

Indeed. Even in the latest builds, if you remove the <svg> element, change it's size and then reinsert it, the <embed> does not resize. :-( It's not an issue that's likely to trip too many people up, but it's a bug nonetheless. (This reminds me of bug 404999 (reflow <object>/<embed> when SVG unloads).)

I guess we can reflow the embedding frame in Init() as you say, checking for NS_FRAME_FIRST_REFLOW.

Comment 31

[Jonathan Watt [:jwatt]]

Err, although checking for NS_FRAME_FIRST_REFLOW would defeat the remove-then-insert-new after load. Hmm... we don't really want to unconditionally reflow the embedding frame in Init().

Comment 32

[Duncan Loveday]

This also reminds me a bit of bug 374308 where changing the display attribute doesn't always fire onload.

This bug seems to be drifting off into oblivion -  the original symptoms are fixed so I think we should either close this or focus on the changes in behaviour between 20080410 and 20080430. The other issues being discussed should be in separate bugs shouldn't they ?

Comment 33

[Boris Zbarsky [:bzbarsky]]

> the original symptoms are fixed

They're not fixed.  They're hidden by a timing change in the loading process.  The discussion is about how to actually fix them so they don't reappear with other timing changes.  I agree that the other issues should have their own bugs (and do, looks like).

Jonathan, why don't we want to unconditionally reflow the embedding frame in Init()?  What's the problem with doing so?

Comment 34

[Duncan Loveday]

> They're not fixed.  They're hidden by a timing change in the loading process. 

Oh I see. So you'll be needing a new test case in order to demonstrate the underlying problem and verify any fix made. Bummer.

Comment 35

[Boris Zbarsky [:bzbarsky]]

Comment 30 describes the testcase needed; sounds to me like Jonathan has one on hand...

Comment 36

[Duncan Loveday]

I'm catching up....slowly

Comment 37

[Robert Longson [:longsonr]]

Fixed by bug 1063073