Closed Bug 240020 Opened 21 years ago Closed 18 years ago

iframes in overflow='hidden' pages can't be zoomed

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bugzillamozilla, Unassigned)

Details

(Keywords: access, testcase, Whiteboard: [dbaron-1.9:RuCe])

Attachments

(1 file)

Testcase
357 bytes, text/html
Details
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head><title>Test</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head> <body onload="document.body.style.overflow='hidden';"> <iframe name="test" src="http://bugzilla.mozilla.org" width="90%" height="90%"></iframe> </body> </html> To reproduce, open the attached testcase and try to zoom the page.
Attached file Testcase —
This testcase was reduced from a page that displays the same problem: http://www.pelemania.com/main.php Prog.
It's also reproducable when you set it to "auto", like this: <body onload="document.body.style.overflow='auto';"> Strange...
Need to change both OS & Hardware to ALL.
OS: Windows XP → All
Hardware: PC → All
confirmed with linux trunk 2004040608 also note that parts of the page other than the iframe still zoom fine. ==> frames
Status: UNCONFIRMED → NEW
Component: Layout → Layout: HTML Frames
Ever confirmed: true
Keywords: testcase
QA Contact: core.layout → core.layout.html-frames
Is this a problem with a static stylesheet, or only with setting it onload? Is this a problem with the patch in bug 234851?
Is this a new bug or a regression?
This is probably not a regression, at least no a recent one. I can reproduce this problem in Mozilla 1.3. Prog.
Mozilla 1.0 did not have this bug, but appeared to completely reload the iframe page when the body's overflow was switched via JS.
Yeah, well the 1.0 behaviour was way worse than this :-)
Debugging shows that the immediate cause of the problem is that here: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/content/base/src/nsDocumentViewer.cpp&rev=1.368&mark=2358#2345 oldTextZoom is already the new value when going through this function for the child content viewer. Now to figure out how it gets that way...
...which is because the two content viewers somehow end up with the same device context when onload="document.body.style.overflow='hidden';" is present on body.
...which is because the code in nsDocumentViewer::Show written for bug 52334 gets the widget's device context instead of the docshell's device context. (Is the docshell still holding on to a different device context? That would seem bad.) So should we try to make the content viewer hold the "right" device context, or should we make the text zoom code deal with it having the wrong one?
Either this or bug 4821 have to block 1.9. When use style none is applied to iframe pages to get iframe content text to be big enough to read, the iframe content invariably falls into a tiny little window that is functionally impossible to use, so there's just no way to access inaccessibly-styled iframe content other than via view source. That's too much to ask of any normal user.
Flags: blocking1.9?
Keywords: access
Flags: blocking1.9? → blocking1.9+
This appears to work just fine... what exactly is the issue?
I can't reproduce this bug anymore in version 2.0.0.3. It probably should be closed.
Whiteboard: [dbaron-1.9:RuCe]
Marking as WFM based on the previous two comments.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → Core Graveyard
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.

Attachment

General

Creator:
Created:
Updated:
Size: