Open
Bug 127981
Opened 23 years ago
Updated 2 years ago
Temporary graphical glitches moving positioned iframe over another iframe
Categories
(Core :: Web Painting, defect, P3)
Core
Web Painting
Tracking
()
NEW
Future
People
(Reporter: brian, Unassigned)
References
()
Details
Attachments
(1 file)
962 bytes,
text/html
|
Details |
Mozilla trunk build 2002022503. Since bug 91516 has been resolved, iframes now paint in the correct order, however, it appears there is still some drawing code which assumes the old behaviour still exists. The given URL is something I came up with by modifying the sticky notes XBL demo to contain iframes. You can see that as you move the note, the existing screen content is moved according to the clipping that would have been in effect before bug 91516 was fixed. As soon as there's a break in the moving them, they get repainted, and everything looks correct again. I would guess this is due to some hack or workaround that can be removed now. CCing Robert O'Callahan, who fixed bug 91516 and may be interested in accepting this one.
Comment 1•23 years ago
|
||
confirmed on linux current trunk.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
Yes, you will see transient badness during scrolling and some updates. As far as I know the only way to fix this is to get rid of the native widgets associated with IFRAMEs (and hopefully almost everything else). The new improved view architecture will help with this but it's still a fair bit of work, so I don't think it can be targeted at 1.0.
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: --- → Future
Comment 3•22 years ago
|
||
The URL in this bug does not work anymore. :-(
Reporter | ||
Comment 4•22 years ago
|
||
The URL itself works. Maybe the server was down at the time, or perhaps you meant to say the testcase is broken. I checked, and there were two issues with it that have come up with the latest build. 1. The second note was moving along with the first one. I took a look with the DOM Inspector and found that it was putting the second div inside the first. I realized that Mozilla has stopped handling <div /> as a closed, empty tag, like it should. As a workaround, I changed it to <div></div>. (Anyone have a bug number?) 2. The iframes in the sticky notes weren't opening mozilla.org and mozillazine.org in them like they used to. I realized that the "inherits=" in the XBL stopped working. I worked around it by hardcoding the URL for the iframes in notes to mozilla.org. This appears to be because of a change in XBL: bug 119317, although I couldn't get xbl:inherits to work either. Perhaps more has changed, but it's not important here. Anyway, the important thing is that I now fixed the testcase so that it is again a good testcase for *this* bug.
Comment 5•22 years ago
|
||
Comment 6•21 years ago
|
||
dont know if this is the same type of behaviour, but at my site, i have noticed that when the cursor goes over a link, the iFrame on the page flickers, and seems to ve drawn in the wrong place, then moved down. Which looks quite ugly. url : http://n30n.isa-geek.org/?p=irc are these the same problem, or should i file another bug ?
Comment 7•20 years ago
|
||
Re: comment 6 I have filed bug 239706 for the problem about the IFRAME appearing briefly in the top of the page. BTW, the testcase in attachment 95902 [details] worksforme using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040404 Firefox/0.8.0+.
Updated•15 years ago
|
Assignee: kmcclusk → nobody
QA Contact: chrispetersen → layout.view-rendering
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Updated•2 years ago
|
Severity: normal → S3
You need to log in
before you can comment on or make changes to this bug.
Description
•