Closed Bug 274600 Opened 20 years ago Closed 18 years ago

Erratic applet rendering when in iframes

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: bugs, Assigned: aaronlev)

References

(
URL
)

Details

(4 keywords)

Attachments

(4 files, 3 obsolete files)

Test case 1
1.64 KB, application/x-zip-compressed
Details
Test case 2
1.97 KB, application/x-zip-compressed
Details
Need to hear from roc as to whether this one makes sense
2.39 KB, patch
roc
: review+
roc
: superreview+
Details | Diff | Splinter Review
tests again
1.94 KB, application/x-gzip-compressed
Details 
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322)
Build Identifier: 

Applets are not rendered as expected. Applets render themselves over other 
iframes when two iframes with java applets are overlapped. Scrolling an iframe 
with an applet causes severe applet flickering. Also observe the applet put 
inside the lower blue iframe when scrolling the red iframe.

Reproducible: Always



Expected Results:  
Applets should stay in their iframe's document content.
Dupe of Bug 221728/invalid i think...
I dont see any direct correlation with bug 221728. Divs are not Iframes.
We have developed a tool using phoenix 0.5. Everything was working as expected. 
From the release of firebird 0.6 to today's release,we believem some 
regressions are introduced. This definitely cant be invalid because it was 
working fine before. If you are conviced, please try the given url with phoenix 
0.5.

regards
Well, I hate this keyboard! Let me rewrite the last sentence. Sorry for the 
spam. 

"If you are not convinced, please try the given url with phoenix 0.5."



It is confirmed that this bug is only exists on Windows operating systems. Our
sparc workstations work as expected on solaris. I have decided to mark this
works for me.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
Is there anybody out there?
The behavior of the page at the URL rendered by mozilla on Linux (and Solaris)
is for sure different from that on Windows. On Linux (I believe that the same is
true of Solaris and other Unix), it's a lot smoother and more stable.

Having said that, I'm not sure which component this belongs to.. OJI?  maybe
not. anyway, I'm adding the owner of OJI to Cc. Sorry if this is a wrong pick.
Status: UNCONFIRMED → NEW
Component: Layout → Java: OJI
Ever confirmed: true
Keywords: pp
Assignee: nobody → kyle.yuan
QA Contact: layout
One big change that has happened in the interaction of Java and frames recently
(in the last 2 years) is that we now support translucent frames and such well. 
Which means that Java plugins that are not windowless will overlap frames
weirdly and such.

I was under the impression that there were Java plugin apis to make the plugin
windowless.  Does doing that help on this testcase?

Failing that, can you possibly narrow down when things broke,maybe using builds
at http://archive.mozilla.org ?  I can provide old Linux nightlies too, but it
doesn't seem like those would help much here...
We are going to prepare a windows machine to try to compile and narrow down the 
problem but the biggest obstacle is that none of my engineers are familiar with 
mozilla sourcebase plus they are overloaded pretty heavily. Neverthless, I 
shall have that in handy as soon as possible. 

I see the translucency is a great thing, but this problem is only available on 
windows builds. As mentioned, it works great on unix and variants. My biggest 
fear is that it may well be a java(TM) plugin related problem, but that is just 
my guess.I hope that it stays as my guess because Sun Microsystems(R) puts 
fixes in this nature into the plugin months later.

Bug Tracker, I saw your comment in bug 227470. Are these two the same issue? If
so, I'm afraid there is nothing to do with java.
Yes, They are the same. Reporter closed the bug as invalid for an unknown 
reason. We have decided to open one ourselves. In fact we used the test case on 
that to create the testcase on our url.

"If so, I'm afraid there is nothing to do with java."

That is great. In fact, phoenix 5.0 works great with the latest plugin. Then 
there must be something missing in mozilla somewhere in the releases made for 
windows after phoenix 5.0. Have you tried the testcase on a windows machine? 

regards,

Yes, I've tried the testcase in bug 227470 and seen the same problem on Windows.
It looks like a layout issue for object frame and obviously it's a
Windows-platform only bug.

Some layout hackers who is mainly working on Windows should take a look.


back to layout
Assignee: kyle.yuan → nobody
Component: Java: OJI → Layout
QA Contact: layout
Keywords: qawanted
I'm not sure we have layout hackers working on Windows (at all, much less mostly)...

ccing roc, since he may end up with a really slow Windows machine for
performance testing and would maybe know something about painting...
just in case, i'm adding masayuki to cc

Please dont ship Firefox 1.1 with this bug in it for windows. We use phonenix 
to demonstrate what our application can do using something other than IE on 
windows. It just doesnt feel right. Since it works on unix, there must be 
something stuck on a platform depended code somewhere. I cross my finders for 
every nightly to see may be automagically this gets fixed, but no luck so far.

Oh well, what time is it? I am outa here.
Keywords: helpwanted
Firefox 1.1 should be out on March. You can set the blocking-aviary1.1 flag to
"?" to get drivers' attention.
Flags: blocking-aviary1.1?
I should be able to fix this soon.

In the meantime, please use http://archive.mozilla.org to narrow down the exact
regression window. Also, some screenshots of minimal testcases would help narrow
it down.
roc, you can use the testcases in bug 227470, they are the same issue.
Great news,

I have checked the nightlies at http://archive.mozilla.org. Mystreously, the 
nightlies needed in the period of the beginning of 2003 till may 2003 are 
missing from the archive. Is there another archive to get those.


Robert, the test case on the given URL describes the problem very well on a 
windows machine.

http://www.neurodna.com/mozilla/
Attached file Test case 1 — 

    
    

    
  

      
      
      
      

        Attached file
          
        Test case 2
        — 
      

    


  
The url given may be down for a while because of hosting company change. In the
mean time, I have attached two testcases including one given at the URL.

sorry for preemptive emails.

    
    

    
  
is there another "nightlies" archive for either phoenix/firebird/firefox or 
mozilla so that I can try to help Robert to zero in what went wrong when.

thanks again

    
    

    
  
There may be private archives (I have one, but only for Linux nightlies, which
won't help here....).  Try asking in the mozillazine forums and maybe in the
mozilla.org newsgroups?

    
    

    
  
(In reply to comment #26)
> archive.mozilla.org?

See comment #18 and comment #20 ;-)


    
    

    
  
Question: if we find which nightly had broken it, how is that going to help? do 
you have version tags for each nightly in the source control system? 

    
    

    
  
Ok this coffee is offically frying my brain; never mind my previous questions.

approximation for the broken code checkin dates:
in between 13-Mar-2003 11:47  and 30-Jun-2003 12:44


    
    

    
  
I now have a much better approximation;

in between 13-Mar-2003 11:47  and 17-May-2003 05:59

    
    

    
  
About 200000 lines of code changed in that time period: 
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-03-13+09%3A00%3A00&maxdate=2003-05-17+09%3A00%3A00&cvsroot=%2Fcvsroot

One checkin that jumps out at me is that for bug 113232.  Does pulling a build
by date for 2003-04-06 sometime show the bug?  What about 2003-04-04?

    
    

    
  
OK, tomorrow I am going to crack this.

I presume 

cvs co -D "2003-04-04" mozilla

is the right way to pull out that date?

    
    

    
  
Actually, the "right" way is to put a line like:

  mk_add_options MOZ_CO_DATE="Sat Feb 19 01:11:14 CST 2005"

(with the appropriate change to the time/timezone as needed, and using any
reasonable date format) in your .mozconfig file.  Note that the Mozilla CVS
server times are all in the Pacific timezone (PDT or PST depending on when in
the year).

    
    

    
  
04-Apr-2003 build has the same problem. It looks like check-in for bug 113232 
aint it. I will pull 30-Mar-2003, and go back 3 days each time I fail to nail 
it.

argh!

    
    

    
  
My previous guessed approximation was wrong

13-Mar-2003 build still has the problem
27-Feb-2003 build works fine

so I will pull 4-Mar-2003 and 8-Mar-2003 on monday, and then finally we will 
hit the jackpot on tuesday.


    
    

    
  
http://bonsai.mozilla.org/cvsquery.cgi?
treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match
&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-02-28+09%
3A00%3A00&maxdate=2003-03-12+09%3A00%3A00&cvsroot=%2Fcvsroot

    
    

    
  
Just a guess! how about Bug 131007? It sounds suspicious.

11-Mar-2003 will be pulled and tested as well.

    
    

    
  
Build for 05-Mar-2003 works
Build for 06-Mar-2003 has the bug

    
    

    
  
Builds from what times on those dates?

    
    

    
  
I didnt give a speficic time while pulling the builds. It must cover the entire 
24 hours for each day.

    
    

    
  
> I didnt give a speficic time while pulling the builds.

It probably pulled for midnight, then... What's the sticky tag (use 'cvs stat'
on a random file)?

    
    

    
  
What does this say? 

Looks like there are none
Looks like there are none

$ cvs stat ProxyJNI.cpp
===================================================================
File: ProxyJNI.cpp      Status: Up-to-date

   Working revision:    1.27
   Repository revision: 1.27    /cvsroot/mozilla/modules/oji/src/ProxyJNI.cpp,v
   Sticky Tag:          (none)
   Sticky Date:         2003.03.04.22.00.00
   Sticky Options:      (none)


    
    

    
  
>   Sticky Date:         2003.03.04.22.00.00

That's a March 4 sticky date...  not so useful for knowing when the March 5/6
builds were pulled.  :(

So assuming the worst, we have about 6000 lines of code changed:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-03-05+00%3A00%3A00&maxdate=2003-03-06+23%3A59%3A59&cvsroot=%2Fcvsroot

In that range, bug 194108 is the only one that looks possibly related...

    
    

    
  
how about bug 194968?

    
    

    
  
Possible, I suppose, but very unlikely in my mind....  Test by doing a checkout
from somewhere in the middle of the day so as to separate the checkins into two
groups?

    
    

    
  
Okey there has been a build confusion (argh!). A gut feeling, plus after 
Boris's comments, I pulled March 6th 2003 again. It looks like I misplaced the 
pulls. March 6th works fine. March 9 had the bug, I am very sure of that. I 
will check March 7 and 8 tomorrow.

Sorry for the confusion 

    
    

    
  
Okey here is the resolution:

March 7th build works fine.
The latest file dates on march 7th pull are
from between March 6th 1:45am and March 6th 12:01pm

March 8th build has the bug.
The latest file dates on march 8th pull are
from between March 7th 12:38am and March 11:58pm

These are not CVS dates, dates of files that I pulled.
I suppose the problem checkin is between March 7th 12:38am and March 11:58pm.


    
    

    
  
Update: 
March 7 2003 pull (again it works fine)

nsHTMLContentSink.cpp, March 6th 2003 11:27, revision 3.0609 (accurate with 
Bonsai)
there are no sticky tag,

well this one below interesting
Although cvs stat for mozilla/xpcom/io/nsFileSpecWin.cpp on my pull gives the 
revision 1.97. But when I look at Bonsai, I see 1.98. Is that a branch checkin?



    
    

    
  
argh! that is mozilla/xpcom/io/nsLocalFileWin.cpp not
mozilla/xpcom/io/nsFileSpecWin.cpp which has revision confusion to me.

    
    

    
  
Ok never mind that confusion, 1.98 has a date for march 7th not march 6th. I am 
getting confused with this thing. Here is what I am very clear of,

Mar 7th 2003 00:00am - 23:59pm pull works ->has files from Mar 6th as latest
Mar 8th 2003 00:00am - 23:59pm pull doesnt work. -> has files from Mar 7th as 
latest

I leave it to you cvs experts to figure out where and what has happened. I have 
to go back to my amounted assignments and clear off my mind. I am sure you guys 
will find where the problem is up there.


    
    

    
  
This one is interesting, in bonsai 3.219 looks like checkedin on march 6th 15:06

Here is what I got frim my march 8th pull, so how accurate bonsai is?

$ cvs stat nsFrameFrame.cpp
===================================================================
File: nsFrameFrame.cpp  Status: Up-to-date

   Working revision:    3.219
   Repository revision: 3.219   /cvsroot/mozilla/layout/html/document/src/Attic/
nsFrameFrame.cpp,v
   Sticky Tag:          (none)
   Sticky Date:         2003.03.07.22.00.00
   Sticky Options:      (none)

    
    

    
  
bug 194968 looks like checkin on march 6th according to Bonsai but here is what 
I got from march 8 pull. It is my major suspect.

$ cvs stat nsWindow.cpp
===================================================================
File: nsWindow.cpp      Status: Up-to-date

   Working revision:    3.464
   Repository revision: 3.464   /cvsroot/mozilla/widget/src/windows/nsWindow.cpp
,v
   Sticky Tag:          (none)
   Sticky Date:         2003.03.07.22.00.00
   Sticky Options:      (none)

    
    

    
  
Based on comment 52, you are specifying just the date (why?  I can't tell...) so
the time sent is 00:00:00 in your timezone.  That seems to be 22:00:00 on the
previous day in the timezone the CVS server is in (pacific time; please let me
know if you're not in Central time, ok?).  So your regression window in Pacific
time is between 2003-03-06 22:00 and 2003-03-07 22:00.  Checkins in that range:

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2003-03-06+22%3A00%3A00&maxdate=2003-03-07+22%3A00%3A00&cvsroot=%2Fcvsroot

Note that bug 194968 is not in that window.

Of that list, nothing looks immediately relevant...

    
    

    
  
I have asked cvs to pull the entire day of March 7th and 8th of 2003. The file 
on comment #52 is just an example. Please see comment #48. The interesting 
thing about bug 194968, according to the bonsai the patch checked in should 
have been included in March 7 pull. But they came with March 8th pull not March 
7th. So March 7 build doesn have the patch in 194968, but March 8 build has.

    
    

    
  
on March 8 build, I will try to remove the patch made for bug 194968, and see 
if it recovers.

    
    

    
  
> I have asked cvs to pull the entire day of March 7th and 8th of 2003.

You can't ask it to do that.  You asked it to pull for a specific moment; that
moment being March 7th (or 8th) midnight your local time.

> But they came with March 8th pull not March 7th.

I'm not sure what made you conclude that... Details?

    
    

    
  
YES! YES!

I removed the patch made by bug 194968, and it worked great.

I suspect the work done in Widget code for windows.

YIPPE!..

    
    

    
  
To aaron based on that comment.
Assignee: nobody → aaronleventhal
Flags: blocking1.8b2?

    
    

    
  
Note bug 196308.  This is probably a similar issue.

    
    

    
  
There are 166 bugs with status "NEW" assigned to Aaron. Robert can you look 
into this so that it may make the Firefix 1.1? I saw your comments on bug 
194968.

thanks

    
  
Keywords: regression

    
    

    
  
Thanks for tracking this down to me :/

Taking a look now.
Status: NEW → ASSIGNED

    
    

    
  


  
This works, but I'm looking into this more deeply.

    
    

    
  


  
I'm not sure what this rule does but I moved it into a clearer place:
-	 if (!initDataPassedIn && GetParent() && 
-	   GetParent()->GetViewManager() != mViewManager)
-	   initData.mListenForResizes = PR_TRUE;
It's a checkin from roc from bug 124685. Robert, can you provide a comment
snippet for what it does that I can add to the patch?

Before I had started mucking with this code in bug 194968, we had only clipped
children if we specifically said so. Then I accidentally stopped clipping the
children. When the flickering bug 196308 occurred, I made it clip children
whenever we were a child window, which seemed to work except it became clear
from this bug that we also need to clip siblings. Rather than take the bold
move of clipping siblings for all child windows, which does seem to work, this
patch may be a safer fix. It only clips siblings when we used to before the
original checkin for bug 194968. However, if everyone thinks we can clip
children and siblings for all child windows then we can use the first patch
(patch 177158: Similar fix as to bug 196308, but clip siblings as well).

        Attachment #177158 -
        Attachment is obsolete: true

        Attachment #177175 -
        Flags: superreview?(roc)

    
    

    
  
Aaron, is that the right diff?  It's identical to the first one you attached...

    
    

    
  


  

        Attachment #177175 -
        Attachment is obsolete: true

        Attachment #177206 -
        Flags: superreview?(roc)

        Attachment #177206 -
        Flags: review?(bzbarsky)

    
    

    
  
I can't really review that patch -- I don't know what that code is doing...

Specifically, how will this affect rendering of iframes when plugins are _not_
involved?

    
    

    
  
Comment on attachment 177206 [details] [diff] [review]
The last patch was supposed to be this one

In theory this patch made sense to me, but Ctrl+tabbing through tab panels was
causing a lot of flashing.

        Attachment #177206 -
        Attachment is obsolete: true

        Attachment #177206 -
        Flags: superreview?(roc)

        Attachment #177206 -
        Flags: review?(bzbarsky)

    
    

    
  


  
Still wondering about this...
-	 if (!initDataPassedIn && GetParent() && 
-	   GetParent()->GetViewManager() != mViewManager)
-	   initData.mListenForResizes = PR_TRUE;
It's a checkin from roc from bug 124685. Robert, can you provide a comment
snippet for what it does that I can add to the patch?

        Attachment #177344 -
        Flags: superreview?(roc)

    
    

    
  
Aaron, is this patch really fixing the problem for this bug? or this is about 
flashing thing? As was mentioned in the comments, the unix versions of firefox 
clips the children just fine. The problem was and is with Windows version of 
firefox. So How the changes in generic code will affect the end result? Have 
you tested your results with URL given on a Windows machine (not linux or 
solaris or alike)?

just curious
thanks

    
    

    
  
I have only tested what this does on a Windows machine, and it fixes the applet
rendering problem at neurodna.

    
    

    
  
Comment on attachment 177344 [details] [diff] [review]
Need to hear from roc as to whether this one makes sense

I think clipping siblings always is fine, in principle.

The listenforresizes stuff is to ensure that when the widget for a toplevel
document is resized, we get an event which will make us do a resize reflow of
the document. This only matters for the outermost widget for each document
because document content gets reflowed entirely under our control.

I'm not sure what that has to do with this patch --- nothing, I think.

        Attachment #177344 -
        Flags: superreview?(roc)

        Attachment #177344 -
        Flags: superreview+

        Attachment #177344 -
        Flags: review+

    
    

    
  
I almost mov(In reply to comment #72)
> I'm not sure what that has to do with this patch --- nothing, I think.
I was considering moving it around. While looking at it I decided it probably
needs a comment, because it's unclear what it does.

Should I checkin a comment based on your text?


    
    

    
  
Checking in view/src/nsView.cpp;
/cvsroot/mozilla/view/src/nsView.cpp,v  <--  nsView.cpp
new revision: 3.215; previous revision: 3.214
done
Checking in layout/generic/nsFrameFrame.cpp;
/cvsroot/mozilla/layout/generic/nsFrameFrame.cpp,v  <--  nsFrameFrame.cpp
new revision: 3.282; previous revision: 3.281
done

Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → FIXED

    
  

        Attachment #177175 -
        Flags: superreview?(roc)

    
    

    
  
It works great, thanks.

    
  
Flags: blocking1.8b2?
Flags: blocking-aviary1.1?

    
    

    
  
Apperantly, the fix does not cover all the isiues, please see the following
I will put some more of test cases.

http://www.neurodna.com/mozilla/test.htm

I cant believe this, I hit the wall again. 
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

    
    

    
  
Our soon to be released application runs flawlessly on gecko based browsers after 2-3 years of work. Please help us get through this bug fix to firefox 2.0. This is a complete deal breaker for us.

thanks and regards,

    
    

    
  
order your iframes in the document in the z-order that you want, and it should work.

    
    

    
  
We change the z-order of iframes all the time.

    
    

    
  
(In reply to comment #77)
> Our soon to be released application runs flawlessly on gecko based browsers
> after 2-3 years of work.

What do you mean? Does it work in FF1.5?

    
    

    
  
What I mean is, our application works great except this bug. This bug has just ruined the entire image of our product ;).

    
    

    
  
>order your iframes in the document in the z-order that you want, and it should
>work.

Is there a way to dynamicaly order them in the document? Lets say the second iframe I add to the document has a lower z-index than the first one, can I re-order them dynamicaly, meaning second will the first,and first will be the second so that they will render correctly?

any ideas? 

    
    

    
  
removing and reinserting iframes according to their z-order works with total
loss of previous inner state of the iframe. It didnt work out. Is there a way to do it in the low level? lets say when the zindex of an iframe changes then reorder all frames in that document accordingly?

just a thought

    
    

    
  
I made a test tool;

http://213.139.192.234/mozilla/testa.htm

    
    

    
  
I no longer have my Windows box to compile the source code, but would patch 177158
work as Aaron suggested in Comment #64?

Aaron, are you out there?

    
    

    
  

      
      
      
      

        Attached file
          
        tests again
        — 
      

    


  
I no longer have my mozilla directory on our web server. 
Here are the tests from that directory. Also I no longer
have my bugs@neurodna.com account.

thanks and good luck,

    
    

    
  
(In reply to comment #76)
> Apperantly, the fix does not cover all the isiues, please see the following
> I will put some more of test cases.
Did these testcases ever work? If so, when did they break exactly?

> I no longer have my Windows box to compile the source code, but would patch
> 177158 work as Aaron suggested in Comment #64?
Sorry, that's not it. Those changes made it in as part of the later patch that roc reviewed. We already have that fix.

You can use Spy++ to look at the windows in your app and see which aren't  children and/or siblings.



    
    

    
  
Apperantly, I dont have my bugs email account so I have to link to this bug to see it. So I may respond late.

The fix you offered helps to the first test case I filed with this bug. That worked well until we needed to change the z-order of the iframes. Then we saw that it was not fixed for all cases. If we have iframe with z-index 30 with an applet in it, and lets say if I open another one with z-index 50 on top of the first one. Applet pops up to the front. Check the test case in the last test bundle, and you will see the problem.

It looks like this is not going to make Firefox 2.0. We are forced to tell our customer to not to use firefox until we tell them to do so. I initially gave the feasibiliy report to my superiors over firefox and am in a pretty bad situation right now. it was my fault, I had to test your fix further. If you may fix this as fast as you can, it will help a lot.

thanks


    
    

    
  
The logic given in Comment #88 is wrong: Here is the correct one
If we have iframe with z-index 50 with an applet in it, and lets say if I open another one with z-index 10 with applet in it.Applet in the second iframe pops up to the front.

file testa.htm in the last test bundle as a dynamic test tool.

    
    

    
  
We are closing this bug. If needed we may file a new one in the future.
We apologize for any inconvenience our engineers caused in participation to
this bug forum which was not authorized by NeuroDNA in anyway.

regards,
Status: REOPENED → RESOLVED
Closed: 20 years ago → 18 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: