All users were logged out of Bugzilla on October 13th, 2018
76 bytes, text/html
113 bytes, text/html
212.28 KB, image/png
407 bytes, text/html
261.94 KB, image/png
140.73 KB, image/png
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.
Attachment #359105 - Attachment description: testcase: (good) a simple iframe with width/height → testcase: a simple iframe with width/height
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.
Created attachment 359108 [details] screenshot of corupted image Also there are render problems when scrolling the page too.
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.
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
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.
(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.
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.
(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
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.
Priority: -- → P3
(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.
(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?
(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?
(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.
It seems like this bug is fixed by bug 512367.
No longer blocks: 512367
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 512367
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.