[PANTHER] iframe content floats out of frame when window is resized

RESOLVED FIXED in Camino0.9

Status

Camino Graveyard
Page Layout
--
critical
RESOLVED FIXED
15 years ago
14 years ago

People

(Reporter: Chris Petersen, Assigned: Mike Pinkerton (not reading bugmail))

Tracking

unspecified
Camino0.9
PowerPC
Mac OS X

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
Build: 2003102915
Platform: 10.3
Expected Results: Whe resizing the page, the iframe content should remain in the
iframe boundaries
What I got: iframe content floats outside of iframe


Steps to reproduce:

I originally saw the behavior at www.maccentral.com which uses a iframe for
several banner ads. But the user will see this will any page that uses a iframe.
See the url for a iframe test that shows this problem.

1) In Camino, open the adove url
2) Notice the iframe content appears in the iframe boundaries
3) Now , resize the window
4) Notice the iframe content floats outside of iframe


I'm going to find when this regressed and report back with the build info.
(Reporter)

Updated

15 years ago
Keywords: regression

Comment 1

15 years ago
wow
(Reporter)

Comment 2

15 years ago
From my testing, this problem only happens when running under 10.3 (7b85). In
addition, it happens with Camino NB's and Camino 0.7 release. Removing
regression keywotrd since this has never worked properly under 10.3. Adding
[PANTHER] to summary to indicate a 10.3 only problem.
Keywords: regression
Summary: iframe content floats out of frame when window is resized → [PANTHER] iframe content floats out of frame when window is resized
(Reporter)

Comment 3

15 years ago
Setting milestone to 0.8 since this needs to be resolved for 0.8
Target Milestone: --- → Camino0.8

Comment 4

15 years ago
Problem shows up for me on 10.3 with Camino build from 10/27/03. Definitely needs to be fixed 
before 0.8.

Comment 5

15 years ago
This needs a fix fast. All of the ads generated by Google are iframes, the web
is looking horrible on 10.3 now :(

Comment 6

15 years ago
How come this behaviour isn't visible in Mozilla 1.6a?

Comment 7

15 years ago
Because Camino uses Cocoa views, but Mozilla is all QuickDraw (and synthetic
widgets).
(Assignee)

Comment 8

15 years ago
this is a bug in panther, test case coming which demonstrates it that has
nothing to do with camino. any text drawn in a QD view with AA turned on will
flail just like this.

thanks, apple.
(Assignee)

Comment 9

15 years ago
Created attachment 135969 [details]
cocoa sample

xcode project demonstrating bug in panther.

Comment 10

15 years ago
Random idea for a workaround... could you clip to the visible rect on all
paints?  In other words, before doing any drawing, push a clip yourself somehow?
(Assignee)

Comment 11

15 years ago
no, because it floats even w/in the frame rect.
(Assignee)

Comment 12

15 years ago
*** Bug 226610 has been marked as a duplicate of this bug. ***

Comment 13

15 years ago
Has this bug already been reported to Apple? If they aren't aware of it, they
won't fix it!

Comment 14

15 years ago
There should be something like the bugzilla-voting feature in Apples
bugreporter/radar :-). I think I already raised that question: Does anyone know
how bugs are handled at Apple? There are plenty of people using Camino and 99%
of them surely think, that this bug is in Camino and not Mac OS X. There should
be a way to escalate such bugs within Apple. I've no idea, whether multiple
submissions help.
(Assignee)

Comment 15

15 years ago
this bug has been reported to apple and, according to them, fixed. There is no
ETA on when the fix will be released.

we've done all we can, now we wait.
(Assignee)

Comment 16

15 years ago
*** Bug 233073 has been marked as a duplicate of this bug. ***

Comment 17

15 years ago
Seems to be fixed!

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040218
MacOS X 10.3.2.

Comment 18

15 years ago
(In reply to comment #17)
> Seems to be fixed!
> 
> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040218
> MacOS X 10.3.2.

No.
The contents of iframe will become inaccurate if a window is resized.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7b) Gecko/20040228
Camino/0.7+

Comment 19

15 years ago
additional comment:
The problem to which not only iframe but the following test cases of bug97283
resembled this occurs.

div using overflow - auto or scroll:
http://bugzilla.mozilla.org/attachment.cgi?id=116880&action=view
(Assignee)

Comment 20

15 years ago
*** Bug 236145 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 21

15 years ago
*** Bug 236146 has been marked as a duplicate of this bug. ***

Comment 22

15 years ago
Got ahold of a 10.3.3 pre-release and it seems to contain the fix for this bug.

Comment 23

15 years ago
10.3.3 is now available via Software Update.

Comment 24

15 years ago
Can still reproduce it in latest nightly with 10.3.3.

Comment 25

15 years ago
Dang, was just about to say the same thing. 

Oh, well.

Comment 26

15 years ago
Very odd. I can go to VersionTracker, which has google adsense iframes, open
links in background tabs, shifting the content down, resize the window and close
the background tabs and nothing happens.

I do soemthing else and it happens. It's a lot more random and less predictable now.

Comment 27

15 years ago
> I do soemthing else and it happens. It's a lot more random and less
predictable now.

by something else I mean just some other stuff, like opening links in a
background tab and it'll float out of bounds. Not neccesarily right after doing
the first part.

Updated

15 years ago
Depends on: 214912
(Assignee)

Comment 28

15 years ago
nothing we can do to fix it, leaving it open so people can find it. moving off
0.8 list.
Status: NEW → ASSIGNED
Target Milestone: Camino0.8 → Camino0.9
Blocks: 226823
No longer blocks: 226823

Comment 29

14 years ago
Solid testing of this bug has been done on the upcomming system update showing
the update does indeed fix the problem.

Let's hope it's also in the final version of the update.

Comment 30

14 years ago
The system update refered to is 10.3.4.

Comment 31

14 years ago
Just an idea...

Perhaps we could alleviate the bad rendering like so:
- on window resize event, detect if system is 10.3.x where x < 4
- if so, start timer to fire at some value like .5 seconds
- if we get another resize event before the timer fires, set the timer back to 0
- when the timer fires, re-layout the whole page if it contains the type of text
that causes problems. If we can't detect if it contains problematic elements
just re-layout always.

This is a slowdown, but its not too slow on a normal-speed machine and it may be
better than horrible rendering. People don't really resize that often, I don't
think.

Thought it might be worth throwing out there.

Comment 32

14 years ago
(In reply to comment #19)
> div using overflow - auto or scroll:
> http://bugzilla.mozilla.org/attachment.cgi?id=116880&action=view


In 10.3.4, this test page also seems to be able to scroll satisfactory.
The page of iframe also seems to be able to display satisfactory.

Mac OS X 10.3.4
2004052621 (v0.8+)

Comment 33

14 years ago
WFM Camino 0.8b and 10.3.4

Comment 34

14 years ago
Bug fixed in Mac OS X 10.3.4. Confirmed by me and lots of other people. Marking
fixed, though it remains a problem for systems 10.3.0-10.3.3. It won't be fixed
on those systems until we move to quartz rendering.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 35

14 years ago
FYI, this is bug also shows itself on www.gmail.com's login page,
https://gmail.google.com/?dest=http%3A%2F%2Fgmail.google.com%2Fgmail

(The iframed "Gmail Sign In" box.)

10.3.4 fixed it for me as well.

Updated

14 years ago
No longer depends on: 214912
You need to log in before you can comment on or make changes to this bug.