All users were logged out of Bugzilla on October 13th, 2018

iframe problem with rendering and image auto zoom

RESOLVED DUPLICATE of bug 512367

Status

()

P3
critical
RESOLVED DUPLICATE of bug 512367
10 years ago
2 months ago

People

(Reporter: zwnj, Unassigned)

Tracking

Trunk
Points:
---
Bug Flags:
blocking1.9.1 -
wanted1.9.1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:investigate])

Attachments

(6 attachments)

(Reporter)

Description

10 years ago
When there's an image in a iframe which is bigger than the iframe, auto zooming makes it smaller, which causes some render problems when changing the zoom, or scrolling the content of the iframe.

There might be problems with non-image formats, but I haven't notice any for HTML, nor PDF.

Going to attach the test-case.
(Reporter)

Comment 1

10 years ago
Created attachment 359104 [details]
testcase: a simple iframe w/o width/height
(Reporter)

Comment 2

10 years ago
Created attachment 359105 [details]
testcase: a simple iframe with width/height
(Reporter)

Updated

10 years ago
Attachment #359105 - Attachment description: testcase: (good) a simple iframe with width/height → testcase: a simple iframe with width/height
(Reporter)

Comment 3

10 years ago
Testcases show that if there are images with auto-zoom in iframes on sites with non-100% site-zoom, firefox gets confused on the images' zoom level.

How to reproduce:
- Open one of the testcases
- Change the zoom to something less that 100% (a few Ctrl+-)
- Test it: change the tab, click on the image to change the zoom level; change tab and come back, etc.
(Reporter)

Comment 4

10 years ago
Created attachment 359108 [details]
screenshot of corupted image

Also there are render problems when scrolling the page too.
(Reporter)

Comment 5

10 years ago
I forgot to mention that the lower narrower part of the image in that screenshot originally belonged to another image, in another iframe at the bottom of the page.
(Reporter)

Comment 6

10 years ago
Also happens under Win XP.  The only difference there is that the mis-rendered part doesn't contain another images' data and is just black.
OS: Linux → All
Hardware: x86 → All

Comment 7

10 years ago
Behnam: it would be best if you separate the two problems into two distinct bugs, and include a set of steps to reproduce the second problem.
(Reporter)

Comment 8

10 years ago
(In reply to comment #7)
> Behnam: it would be best if you separate the two problems into two distinct
> bugs, and include a set of steps to reproduce the second problem.

I didn't to that because I think they have the same source.

Going to attach a better testcase.
(Reporter)

Comment 9

10 years ago
Created attachment 359515 [details]
testcase: two frames with two big pictures from flickr.com
(Reporter)

Comment 10

10 years ago
Just open the page and change the site-zoom to bigger than 100%, then click on the pictures to zoom and move around to see what happens.
(Reporter)

Comment 11

10 years ago
Created attachment 359518 [details]
screenshot of testcase 3, on 120% site-zoom
(Reporter)

Comment 12

10 years ago
Created attachment 359519 [details]
screenshot of testcase 3, on 100% site-zoom (no problem)

Comment 13

10 years ago
(In reply to comment #10)
> Just open the page and change the site-zoom to bigger than 100%, then click on
> the pictures to zoom and move around to see what happens.

What I'm experiencing (in addition to the rendering problems) is that the image breaks the bounds of the containing iframe, which can potentially be used to cover parts of the parent frame.  I don't know if it can be used in an attack, but it's worth considering as a potential security problem.

I think any bug which can cause the contents of a frame to cover the contents of parent frames should be considered a blocker.
Severity: major → critical
Flags: blocking1.9.1?
Whiteboard: [sg:investigate]
Version: unspecified → Trunk
While I agree that there's a potential security issue here, I don't think this blocks as the chain of social hacks and spoofing is pretty deeply chained.
Flags: blocking1.9.1? → blocking1.9.1-
IMHO we should just turn off all the auto-zoom and user-zoom features for non-toplevel image documents. That shouldn't be too hard.
Flags: wanted1.9.1+
Priority: -- → P3

Comment 16

10 years ago
(In reply to comment #15)
> IMHO we should just turn off all the auto-zoom and user-zoom features for
> non-toplevel image documents. That shouldn't be too hard.

IINM this should be done in nsImageDocument by detecting whether we are a top-level document, and set mResizeImageByDefault accordingly (to disable auto-zoom), and also adding event handlers in nsImageDocument::SetScriptGlobalObject only if we're top-level, thus disabling user-zoom.

The only thing which I couldn't figure out is how to detect whether we're a top-level document.  I'll have a patch if you can give me a pointer in that regard.  :-)
I'm not sure of the best way to do that. You could just disable the behaviour when the docshell's parent (found via nsIDocShellTreeItem) is chrome, but I actually think that in an ideal world, Gecko would not have these behaviours by default, and Firefox would be responsible for implementing or at least enabling them in image documents in tabs. Gavin, what do you think?
(In reply to comment #17)
> I'm not sure of the best way to do that. You could just disable the behaviour
> when the docshell's parent (found via nsIDocShellTreeItem) is chrome,

Of course, I meant content.
Just a question: is a toplevel standalone image that's bigger than the browser window also broken on a site where the user has a non-identity preferred zoom for the site?

As far as enabling or disabling this, I think it makes the most sense for the behavior to live in Gecko and for apps to enable/disable via prefs (as we do now).  Checking for a toplevel same-type docshell makes sense to me if the problem is really limited to subframes, but see the first paragraph of this comment.
It's not just because of this problem that we should disable the UI behaviour for subframes. I think if a page decides to use an <iframe>ed image, we shouldn't mess with it.
Yeah, fair enough.
It sounds like Ehsan can just go with the docshell parent type check then.
I'd check whether the given docshell is its own same-type root, I think.

Comment 24

10 years ago
(In reply to comment #23)
> I'd check whether the given docshell is its own same-type root, I think.

Is this different with comment 22?  By "same-type root" you mean that if the current docshell is content, the parent should be chrome and vice versa?  I think that would be wrong, because a chrome docshell can't have a content docshell as its parent (or can it?)
> Is this different with comment 22? 

Subtly.  Instead of checking for specific types, you just check whether your docshell is the root docshell of its type.

> a chrome docshell can't have a content docshell as its parent

That's true, but do you really want to be assuming that only two docshell types exist and the exact relationship between them?

Comment 26

10 years ago
(In reply to comment #25)
> > Is this different with comment 22? 
> 
> Subtly.  Instead of checking for specific types, you just check whether your
> docshell is the root docshell of its type.

I see.  Thanks for the explanation.

> > a chrome docshell can't have a content docshell as its parent
> 
> That's true, but do you really want to be assuming that only two docshell types
> exist and the exact relationship between them?

Probably not!  :-)
Related to bug 495894?

Comment 28

9 years ago
(In reply to comment #27)
> Related to bug 495894?

I think that bug is a dupe of this one.  I'll mark it as such.

Updated

9 years ago
Duplicate of this bug: 495894
It seems like this bug is fixed by bug 512367.
Indeed.
No longer blocks: 512367
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 512367

Updated

2 months ago
Product: Core → Core Graveyard
(Assignee)

Updated

2 months ago
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.