I am still trying to make progress on a question I have asked about before. Maybe someone can at least help with what the expected behavior is so I can where to go next.
When you are looking at a page in one frame of a frame set, and you move to a new page in that frame, is the expectation that Firebug will track the page change and display the new HTML?
I work on a site where that does not seem to happen, at least not consistently. My only option is to navigate to the page in question and then turn on Firebug.
It may be that there is something peculiar about the design of this particular site that causes this, but to find that I need to know first what normally happens in this situation. Maybe there is something about the way Firebug tracks the HTML that the particular site design is defeating.
Depending on what the expectation and the intent are, perhaps some relief could be provided by a way to refresh the HTML display (hopefully with the correct current content of course). I think I have seen others request something along those lines too.
tabWatcher.js controls activation of Firebug upon page loads. It relies on pagehide, pageshow, and DOMContentLoaded events plus some other mysterious stuff. If the frame page change provides the event sequence as in a normal page load, then I would expect Firebug to track the page change. Else I don't know what to expect.
The underlying problem here is the same as XSLT: the FF engine does not document its load process.
I can help you trace the load events with the code on branches/explore if you want to try it.
On Jul 10, 11:32 am, BobH <r.hassin...@ieee.org> wrote:
> I am still trying to make progress on a question I have asked about > before. Maybe someone can at least help with what the expected > behavior is so I can where to go next.
> When you are looking at a page in one frame of a frame set, and you > move to a new page in that frame, is the expectation that Firebug will > track the page change and display the new HTML?
> I work on a site where that does not seem to happen, at least not > consistently. My only option is to navigate to the page in question > and then turn on Firebug.
> It may be that there is something peculiar about the design of this > particular site that causes this, but to find that I need to know > first what normally happens in this situation. Maybe there is > something about the way Firebug tracks the HTML that the particular > site design is defeating.
> Depending on what the expectation and the intent are, perhaps some > relief could be provided by a way to refresh the HTML display > (hopefully with the correct current content of course). I think I > have seen others request something along those lines too.
Thanks John. I think you are saying that under normal conditions you do expect page changes within frames to work correctly. That is a help.
There are some places in this application where there are old efforts to defeat caching along the Internet using meta statements and maybe a few other oddities, but generally on the client end it is just pretty much ordinary CGI based links circa 1998-1999. Very little if any Javascript, AJAX, etc. in many of the areas where I see the problems.
I am not sure I am sufficiently up to speed with the Firefox work to find, let alone use code on branches/explore, particularly in the context of this application. Pending that I will start with looking more deaply at the application running with Firefox and see if I can narrow down the symptoms.
Bob
On Jul 11, 12:17 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> tabWatcher.js controls activation of Firebug upon page loads. It > relies on pagehide, pageshow, and DOMContentLoaded events plus some > other mysterious stuff. If the frame page change provides the event > sequence as in a normal page load, then I would expect Firebug to > track the page change. Else I don't know what to expect.
> The underlying problem here is the same as XSLT: the FF engine does > not document its load process.
> I can help you trace the load events with the code on branches/explore > if you want to try it.
> On Jul 10, 11:32 am, BobH <r.hassin...@ieee.org> wrote:
> > Hi all,
> > I am still trying to make progress on a question I have asked about > > before. Maybe someone can at least help with what the expected > > behavior is so I can where to go next.
> > When you are looking at a page in one frame of a frame set, and you > > move to a new page in that frame, is the expectation that Firebug will > > track the page change and display the new HTML?
> > I work on a site where that does not seem to happen, at least not > > consistently. My only option is to navigate to the page in question > > and then turn on Firebug.
> > It may be that there is something peculiar about the design of this > > particular site that causes this, but to find that I need to know > > first what normally happens in this situation. Maybe there is > > something about the way Firebug tracks the HTML that the particular > > site design is defeating.
> > Depending on what the expectation and the intent are, perhaps some > > relief could be provided by a way to refresh the HTML display > > (hopefully with the correct current content of course). I think I > > have seen others request something along those lines too.
> Thanks John. I think you are saying that under normal conditions you > do expect page changes within frames to work correctly. That is a > help.
> There are some places in this application where there are old efforts > to defeat caching along the Internet using meta statements and maybe a > few other oddities, but generally on the client end it is just pretty > much ordinary CGI based links circa 1998-1999. Very little if any > Javascript, AJAX, etc. in many of the areas where I see the problems.
> I am not sure I am sufficiently up to speed with the Firefox work to > find, let alone use code on branches/explore, particularly in the > context of this application. Pending that I will start with looking > more deaply at the application running with Firefox and see if I can > narrow down the symptoms.
> Bob
> On Jul 11, 12:17 am, John J Barton <johnjbar...@johnjbarton.com> > wrote:
> > tabWatcher.js controls activation of Firebug upon page loads. It > > relies on pagehide, pageshow, and DOMContentLoaded events plus some > > other mysterious stuff. If the frame page change provides the event > > sequence as in a normal page load, then I would expect Firebug to > > track the page change. Else I don't know what to expect.
> > The underlying problem here is the same as XSLT: the FF engine does > > not document its load process.
> > I can help you trace the load events with the code on branches/explore > > if you want to try it.
> > On Jul 10, 11:32 am, BobH <r.hassin...@ieee.org> wrote:
> > > Hi all,
> > > I am still trying to make progress on a question I have asked about > > > before. Maybe someone can at least help with what the expected > > > behavior is so I can where to go next.
> > > When you are looking at a page in one frame of a frame set, and you > > > move to a new page in that frame, is the expectation that Firebug will > > > track the page change and display the new HTML?
> > > I work on a site where that does not seem to happen, at least not > > > consistently. My only option is to navigate to the page in question > > > and then turn on Firebug.
> > > It may be that there is something peculiar about the design of this > > > particular site that causes this, but to find that I need to know > > > first what normally happens in this situation. Maybe there is > > > something about the way Firebug tracks the HTML that the particular > > > site design is defeating.
> > > Depending on what the expectation and the intent are, perhaps some > > > relief could be provided by a way to refresh the HTML display > > > (hopefully with the correct current content of course). I think I > > > have seen others request something along those lines too.
OK John. Making the simple case is more or less in line with sorting through what may be happening.
I am still hopeful though that *someone* here has seen Firebug work (or not work) in a frames setting. I know frames are said to be going out of fashion but there are still places where they are needed and used.
On Jul 11, 1:13 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Sorry I wasn't clear: I don't know what to expect for frames. Try > making a simple case with frames to see what Firebug does with that.
> On Jul 10, 10:08 pm, BobH <r.hassin...@ieee.org> wrote:
> > Thanks John. I think you are saying that under normal conditions you > > do expect page changes within frames to work correctly. That is a > > help.
> > There are some places in this application where there are old efforts > > to defeat caching along the Internet using meta statements and maybe a > > few other oddities, but generally on the client end it is just pretty > > much ordinary CGI based links circa 1998-1999. Very little if any > > Javascript, AJAX, etc. in many of the areas where I see the problems.
> > I am not sure I am sufficiently up to speed with the Firefox work to > > find, let alone use code on branches/explore, particularly in the > > context of this application. Pending that I will start with looking > > more deaply at the application running with Firefox and see if I can > > narrow down the symptoms.
> > Bob
> > On Jul 11, 12:17 am, John J Barton <johnjbar...@johnjbarton.com> > > wrote:
> > > tabWatcher.js controls activation of Firebug upon page loads. It > > > relies on pagehide, pageshow, and DOMContentLoaded events plus some > > > other mysterious stuff. If the frame page change provides the event > > > sequence as in a normal page load, then I would expect Firebug to > > > track the page change. Else I don't know what to expect.
> > > The underlying problem here is the same as XSLT: the FF engine does > > > not document its load process.
> > > I can help you trace the load events with the code on branches/explore > > > if you want to try it.
> > > > I am still trying to make progress on a question I have asked about > > > > before. Maybe someone can at least help with what the expected > > > > behavior is so I can where to go next.
> > > > When you are looking at a page in one frame of a frame set, and you > > > > move to a new page in that frame, is the expectation that Firebug will > > > > track the page change and display the new HTML?
> > > > I work on a site where that does not seem to happen, at least not > > > > consistently. My only option is to navigate to the page in question > > > > and then turn on Firebug.
> > > > It may be that there is something peculiar about the design of this > > > > particular site that causes this, but to find that I need to know > > > > first what normally happens in this situation. Maybe there is > > > > something about the way Firebug tracks the HTML that the particular > > > > site design is defeating.
> > > > Depending on what the expectation and the intent are, perhaps some > > > > relief could be provided by a way to refresh the HTML display > > > > (hopefully with the correct current content of course). I think I > > > > have seen others request something along those lines too.
When I click on the form submit button, it calls itself to process the form. However, because of form variable data, an entirely NEW page is dynamically rendered, with completely different JavaScript.
Firebug 1.05 seems not to notice and still shows the JavaScript from the previous form, and I'm unable to debug the new page using breakpoints, etc.
I don't know if this scenario relates directly to the problems I am trying to resolve, but the general "Firebug does not notice the change" idea is right in line. It would be interesting to understand more about the way(s) Firebug notices when there is a change, and what is involved in picking it up.
If the change has to be picked up as it goes by (downloads/whatever) then there is no choice except to identify each case where there is a failure to catch a change and fix it. But if Firebug can update the Javascript and so on after the fact then the idea of a mechanisum to mannually trigger an update has value. Best is to fix everything, but really good is to have a tool that allows working around problems until they can be identified and fixed (assuming they even CAN be fixed).
On Jul 12, 1:35 pm, David Zechiel <dzech...@gmail.com> wrote:
> When I click on the form submit button, it calls itself to process the > form. However, because of form variable data, an entirely NEW page is > dynamically rendered, with completely different JavaScript.
> Firebug 1.05 seems not to notice and still shows the JavaScript from > the previous form, and I'm unable to debug the new page using > breakpoints, etc.
> I don't know if this scenario relates directly to the problems I am > trying to resolve, but the general "Firebug does not notice the > change" idea is right in line. It would be interesting to understand > more about the way(s) Firebug notices when there is a change, and what > is involved in picking it up.
> If the change has to be picked up as it goes by (downloads/whatever) > then there is no choice except to identify each case where there is a > failure to catch a change and fix it. But if Firebug can update the > Javascript and so on after the fact then the idea of a mechanisum to > mannually trigger an update has value. Best is to fix everything, but > really good is to have a tool that allows working around problems > until they can be identified and fixed (assuming they even CAN be > fixed).
> On Jul 12, 1:35 pm, David Zechiel <dzech...@gmail.com> wrote:
> > When I click on the form submit button, it calls itself to process the > > form. However, because of form variable data, an entirely NEW page is > > dynamically rendered, with completely different JavaScript.
> > Firebug 1.05 seems not to notice and still shows the JavaScript from > > the previous form, and I'm unable to debug the new page using > > breakpoints, etc.
That is a fairly simple, but interesting case. There are four frames. The lower right one "Main", starts empty, then an onLoad in the top level frameset initializes it to one of the pages that can appear there. Then onMouseovers in the links in the left frame ("LeftNav") change the content of Main.
The Firebug HTML display does not pick up the result of the onLoad, and does not pick up the results of the onMouseovers. It continues to see just the initial empty page with its background.
It does seem that FB can display the DOM for whatever is current however,.
The fix only deals with updates on document Node that are not the root of the HTML view. I guess that is frames whose document is updated wholesale.
Firebug does not watch frames because it is intended to catch frame updates via mutate events. But it missed one case: the update is the whole frame document.
Or so I guess. I don't really understand the DOM for frames.
John.
On Jul 14, 8:46 am, BobH <r.hassin...@ieee.org> wrote:
> That is a fairly simple, but interesting case. There are four > frames. The lower right one "Main", starts empty, then an onLoad in > the top level frameset initializes it to one of the pages that can > appear there. Then onMouseovers in the links in the left frame > ("LeftNav") change the content of Main.
> The Firebug HTML display does not pick up the result of the onLoad, > and does not pick up the results of the onMouseovers. It continues to > see just the initial empty page with its background.
> It does seem that FB can display the DOM for whatever is current > however,.
As a newcommer I am not familiar with the way all this works. I don't see where or what r66 is, and I don't know if I can take advantage of it now, or if the process is to wait for it to be incorporated into a new Firebug version.
On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> The fix only deals with updates on document Node that are not the root > of the HTML view. I guess that is frames whose document is updated > wholesale.
> Firebug does not watch frames because it is intended to catch frame > updates via mutate events. But it missed one case: the update is the > whole frame document.
> Or so I guess. I don't really understand the DOM for frames.
> John.
> On Jul 14, 8:46 am, BobH <r.hassin...@ieee.org> wrote:
> > Thanks John. Looks like a bit of a learning curve to really get into > > all that, which I will work on.
> > FWIW I did note around lines 393-411 a section that includes the > > comment:
> > // Only watch windows that are their own parent - e.g. not frames
> > and some commented out code. Maybe a clue?
> > It would be interesting to understand the reasons for that design.
> > I started looking for an easily viewed case that I am familiar with to > > try FB against a frames based page and noted the one here:
> > That is a fairly simple, but interesting case. There are four > > frames. The lower right one "Main", starts empty, then an onLoad in > > the top level frameset initializes it to one of the pages that can > > appear there. Then onMouseovers in the links in the left frame > > ("LeftNav") change the content of Main.
> > The Firebug HTML display does not pick up the result of the onLoad, > > and does not pick up the results of the onMouseovers. It continues to > > see just the initial empty page with its background.
> > It does seem that FB can display the DOM for whatever is current > > however,.- Hide quoted text -
That branch is a filtered copy of another branch, https://fbug.googlecode.com/svn/branches/explore The filter removes debug statements I need to work on the code. I add stuff to this branch incrementally then move it on to branches/ eval every couple of weeks. Then Xucia.com builds that branch for you.
> As a newcommer I am not familiar with the way all this works. I don't > see where or what r66 is, and I don't know if I can take advantage of > it now, or if the process is to wait for it to be incorporated into a > new Firebug version.
> On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > Fix is in r66 on branches/explore.
> > The fix only deals with updates on document Node that are not the root > > of the HTML view. I guess that is frames whose document is updated > > wholesale.
> > Firebug does not watch frames because it is intended to catch frame > > updates via mutate events. But it missed one case: the update is the > > whole frame document.
> > Or so I guess. I don't really understand the DOM for frames.
> > John.
> > On Jul 14, 8:46 am, BobH <r.hassin...@ieee.org> wrote:
> > > Thanks John. Looks like a bit of a learning curve to really get into > > > all that, which I will work on.
> > > FWIW I did note around lines 393-411 a section that includes the > > > comment:
> > > // Only watch windows that are their own parent - e.g. not frames
> > > and some commented out code. Maybe a clue?
> > > It would be interesting to understand the reasons for that design.
> > > I started looking for an easily viewed case that I am familiar with to > > > try FB against a frames based page and noted the one here:
> > > That is a fairly simple, but interesting case. There are four > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > the top level frameset initializes it to one of the pages that can > > > appear there. Then onMouseovers in the links in the left frame > > > ("LeftNav") change the content of Main.
> > > The Firebug HTML display does not pick up the result of the onLoad, > > > and does not pick up the results of the onMouseovers. It continues to > > > see just the initial empty page with its background.
> > > It does seem that FB can display the DOM for whatever is current > > > however,.- Hide quoted text -
I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement in the problem I am seeing on my site, nor do I see an improvement in the site at http://users.rcn.com/ieeeworc/.
I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I can find to the FF3a5 that was mentioned. I don't see that the combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact that seems to be broken more (I see multiple <html> s in the HTML display, and the at least part of the time links don't seem to work.
On Jul 15, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > The filter removes debug statements I need to work on the code. > I add stuff to this branch incrementally then move it on to branches/ > eval every couple of weeks. Then Xucia.com builds that branch for > you.
> On Jul 15, 9:31 am, BobH <r.hassin...@ieee.org> wrote:
> > That sounds hopeful John.
> > As a newcommer I am not familiar with the way all this works. I don't > > see where or what r66 is, and I don't know if I can take advantage of > > it now, or if the process is to wait for it to be incorporated into a > > new Firebug version.
> > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > Fix is in r66 on branches/explore.
> > > The fix only deals with updates on document Node that are not the root > > > of the HTML view. I guess that is frames whose document is updated > > > wholesale.
> > > Firebug does not watch frames because it is intended to catch frame > > > updates via mutate events. But it missed one case: the update is the > > > whole frame document.
> > > Or so I guess. I don't really understand the DOM for frames.
> > > > That is a fairly simple, but interesting case. There are four > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > the top level frameset initializes it to one of the pages that can > > > > appear there. Then onMouseovers in the links in the left frame > > > > ("LeftNav") change the content of Main.
> > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > and does not pick up the results of the onMouseovers. It continues to > > > > see just the initial empty page with its background.
> > > > It does seem that FB can display the DOM for whatever is current > > > > however,.- Hide quoted text -
> Sorry to not know more about how all this works.
> I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons > now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement > in the problem I am seeing on my site, nor do I see an improvement in > the site athttp://users.rcn.com/ieeeworc/.
> I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I > can find to the FF3a5 that was mentioned. I don't see that the > combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact > that seems to be broken more (I see multiple <html> s in the HTML > display, and the at least part of the time links don't seem to work.
> On Jul 15, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> > wrote:
> > That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > > The filter removes debug statements I need to work on the code. > > I add stuff to this branch incrementally then move it on to branches/ > > eval every couple of weeks. Then Xucia.com builds that branch for > > you.
> > On Jul 15, 9:31 am, BobH <r.hassin...@ieee.org> wrote:
> > > That sounds hopeful John.
> > > As a newcommer I am not familiar with the way all this works. I don't > > > see where or what r66 is, and I don't know if I can take advantage of > > > it now, or if the process is to wait for it to be incorporated into a > > > new Firebug version.
> > > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > Fix is in r66 on branches/explore.
> > > > The fix only deals with updates on document Node that are not the root > > > > of the HTML view. I guess that is frames whose document is updated > > > > wholesale.
> > > > Firebug does not watch frames because it is intended to catch frame > > > > updates via mutate events. But it missed one case: the update is the > > > > whole frame document.
> > > > Or so I guess. I don't really understand the DOM for frames.
> > > > > That is a fairly simple, but interesting case. There are four > > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > > the top level frameset initializes it to one of the pages that can > > > > > appear there. Then onMouseovers in the links in the left frame > > > > > ("LeftNav") change the content of Main.
> > > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > > and does not pick up the results of the onMouseovers. It continues to > > > > > see just the initial empty page with its background.
> > > > > It does seem that FB can display the DOM for whatever is current > > > > > however,.- Hide quoted text -
Yes it looks like my "fix" did not work. But I am puzzled by your comment "I see multiple <html> s in the HTML display", because that is what I saw when I thought it was fixed.
I think the problem is in the html.mutateNode code, which is why the initial display works, but the update does not. This code creates a "parallel universe", a set of nodes to put in the HTML panel to represent the user's DOM. For your test case, the process comes up with a null box, hence no updates to the view.
I'll keep looking.
John.
On Jul 15, 2:26 pm, BobH <r.hassin...@ieee.org> wrote:
> Sorry to not know more about how all this works.
> I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons > now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement > in the problem I am seeing on my site, nor do I see an improvement in > the site athttp://users.rcn.com/ieeeworc/.
> I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I > can find to the FF3a5 that was mentioned. I don't see that the > combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact > that seems to be broken more (I see multiple <html> s in the HTML > display, and the at least part of the time links don't seem to work.
> On Jul 15, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> > wrote:
> > That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > > The filter removes debug statements I need to work on the code. > > I add stuff to this branch incrementally then move it on to branches/ > > eval every couple of weeks. Then Xucia.com builds that branch for > > you.
> > On Jul 15, 9:31 am, BobH <r.hassin...@ieee.org> wrote:
> > > That sounds hopeful John.
> > > As a newcommer I am not familiar with the way all this works. I don't > > > see where or what r66 is, and I don't know if I can take advantage of > > > it now, or if the process is to wait for it to be incorporated into a > > > new Firebug version.
> > > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > Fix is in r66 on branches/explore.
> > > > The fix only deals with updates on document Node that are not the root > > > > of the HTML view. I guess that is frames whose document is updated > > > > wholesale.
> > > > Firebug does not watch frames because it is intended to catch frame > > > > updates via mutate events. But it missed one case: the update is the > > > > whole frame document.
> > > > Or so I guess. I don't really understand the DOM for frames.
> > > > > That is a fairly simple, but interesting case. There are four > > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > > the top level frameset initializes it to one of the pages that can > > > > > appear there. Then onMouseovers in the links in the left frame > > > > > ("LeftNav") change the content of Main.
> > > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > > and does not pick up the results of the onMouseovers. It continues to > > > > > see just the initial empty page with its background.
> > > > > It does seem that FB can display the DOM for whatever is current > > > > > however,.- Hide quoted text -
Ok, I fixed it this time really ;-). I had the right problem but the wrong fix. Firebug has no representation for "document element", so when a mutateNode event comes in with the parentNode of document element, the representation cannot be updated. I inserted two lines: mutateNode: function(target, parent, nextSibling, removal) { if (parent.nodeType == 9) parent = parent.documentElement;
this.markChange(); to cause the parent to become the <html> element. Now the update shows up like any other node, highlighted in yellow etc.
I created a new release, firebug-1.1eval.94.1.05.xpi with just this update. In the process I discovered that Firebug blocks UI updated on FF3.0a6 when you refresh the page. So unfortunately this combination is not working yet. Hopefully the firebug-1.1eval.94.1.05.xpi will work in FF2; if you try it I would appreciate feedback.
John.
On Jul 15, 6:23 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Yes it looks like my "fix" did not work. But I am puzzled by your > comment "I see multiple <html> s in the HTML display", because that is > what I saw when I thought it was fixed.
> I think the problem is in the html.mutateNode code, which is why the > initial display works, but the update does not. This code creates a > "parallel universe", a set of nodes to put in the HTML panel to > represent the user's DOM. For your test case, the process comes up > with a null box, hence no updates to the view.
> I'll keep looking.
> John.
> On Jul 15, 2:26 pm, BobH <r.hassin...@ieee.org> wrote:
> > Sorry to not know more about how all this works.
> > I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons > > now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement > > in the problem I am seeing on my site, nor do I see an improvement in > > the site athttp://users.rcn.com/ieeeworc/.
> > I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I > > can find to the FF3a5 that was mentioned. I don't see that the > > combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact > > that seems to be broken more (I see multiple <html> s in the HTML > > display, and the at least part of the time links don't seem to work.
> > On Jul 15, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> > > wrote:
> > > That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > > > The filter removes debug statements I need to work on the code. > > > I add stuff to this branch incrementally then move it on to branches/ > > > eval every couple of weeks. Then Xucia.com builds that branch for > > > you.
> > > > As a newcommer I am not familiar with the way all this works. I don't > > > > see where or what r66 is, and I don't know if I can take advantage of > > > > it now, or if the process is to wait for it to be incorporated into a > > > > new Firebug version.
> > > > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > > Fix is in r66 on branches/explore.
> > > > > The fix only deals with updates on document Node that are not the root > > > > > of the HTML view. I guess that is frames whose document is updated > > > > > wholesale.
> > > > > Firebug does not watch frames because it is intended to catch frame > > > > > updates via mutate events. But it missed one case: the update is the > > > > > whole frame document.
> > > > > Or so I guess. I don't really understand the DOM for frames.
> > > > > > Thanks John. Looks like a bit of a learning curve to really get into > > > > > > all that, which I will work on.
> > > > > > FWIW I did note around lines 393-411 a section that includes the > > > > > > comment:
> > > > > > // Only watch windows that are their own parent - e.g. not frames
> > > > > > and some commented out code. Maybe a clue?
> > > > > > It would be interesting to understand the reasons for that design.
> > > > > > I started looking for an easily viewed case that I am familiar with to > > > > > > try FB against a frames based page and noted the one here:
> > > > > > That is a fairly simple, but interesting case. There are four > > > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > > > the top level frameset initializes it to one of the pages that can > > > > > > appear there. Then onMouseovers in the links in the left frame > > > > > > ("LeftNav") change the content of Main.
> > > > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > > > and does not pick up the results of the onMouseovers. It continues to > > > > > > see just the initial empty page with its background.
> > > > > > It does seem that FB can display the DOM for whatever is current > > > > > > however,.- Hide quoted text -
I tracked down firebug-1.1eval.94.1.05.xpi and installed it on a new download of FB 1.05 under FF 2.0.0.4 (e.g. apparently without firebug-1.1eval.93.1.05.xpi - I don't know another way to undo that). I tried it against the small test case and it still did not work correctly. Would firebug-1.1eval.93.1.05.xpi be required, or is there some other problem?
BTW - I am not sure if I was clear about the multiple <HTML>s when trying with FF 3. The frames case always shows an <HTML> for the frame set and for each frame. What I noted was that <HTML>s seemed to be accumulating - I think under one of the pages within the frameset (although I don't recall exactly at this point).
On Jul 16, 12:38 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> Ok, I fixed it this time really ;-). I had the right problem but the > wrong fix. Firebug has no representation for "document element", so > when a mutateNode event comes in with the parentNode of document > element, the representation cannot be updated. I inserted two lines: > mutateNode: function(target, parent, nextSibling, removal) > { > if (parent.nodeType == 9) > parent = parent.documentElement;
> this.markChange(); > to cause the parent to become the <html> element. Now the update shows > up like any other node, highlighted in yellow etc.
> I created a new release, firebug-1.1eval.94.1.05.xpi with just this > update. In the process I discovered that Firebug blocks UI updated on > FF3.0a6 when you refresh the page. So unfortunately this combination > is not working yet. Hopefully the firebug-1.1eval.94.1.05.xpi will > work in FF2; if you try it I would appreciate feedback.
> John.
> On Jul 15, 6:23 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > Yes it looks like my "fix" did not work. But I am puzzled by your > > comment "I see multiple <html> s in the HTML display", because that is > > what I saw when I thought it was fixed.
> > I think the problem is in the html.mutateNode code, which is why the > > initial display works, but the update does not. This code creates a > > "parallel universe", a set of nodes to put in the HTML panel to > > represent the user's DOM. For your test case, the process comes up > > with a null box, hence no updates to the view.
> > I'll keep looking.
> > John.
> > On Jul 15, 2:26 pm, BobH <r.hassin...@ieee.org> wrote:
> > > Sorry to not know more about how all this works.
> > > I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons > > > now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement > > > in the problem I am seeing on my site, nor do I see an improvement in > > > the site athttp://users.rcn.com/ieeeworc/.
> > > I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I > > > can find to the FF3a5 that was mentioned. I don't see that the > > > combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact > > > that seems to be broken more (I see multiple <html> s in the HTML > > > display, and the at least part of the time links don't seem to work.
> > > On Jul 15, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> > > > wrote:
> > > > That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > > > > The filter removes debug statements I need to work on the code. > > > > I add stuff to this branch incrementally then move it on to branches/ > > > > eval every couple of weeks. Then Xucia.com builds that branch for > > > > you.
> > > > > As a newcommer I am not familiar with the way all this works. I don't > > > > > see where or what r66 is, and I don't know if I can take advantage of > > > > > it now, or if the process is to wait for it to be incorporated into a > > > > > new Firebug version.
> > > > > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > > > Fix is in r66 on branches/explore.
> > > > > > The fix only deals with updates on document Node that are not the root > > > > > > of the HTML view. I guess that is frames whose document is updated > > > > > > wholesale.
> > > > > > Firebug does not watch frames because it is intended to catch frame > > > > > > updates via mutate events. But it missed one case: the update is the > > > > > > whole frame document.
> > > > > > Or so I guess. I don't really understand the DOM for frames.
> > > > > > > Thanks John. Looks like a bit of a learning curve to really get into > > > > > > > all that, which I will work on.
> > > > > > > FWIW I did note around lines 393-411 a section that includes the > > > > > > > comment:
> > > > > > > // Only watch windows that are their own parent - e.g. not frames
> > > > > > > and some commented out code. Maybe a clue?
> > > > > > > It would be interesting to understand the reasons for that design.
> > > > > > > I started looking for an easily viewed case that I am familiar with to > > > > > > > try FB against a frames based page and noted the one here:
> > > > > > > That is a fairly simple, but interesting case. There are four > > > > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > > > > the top level frameset initializes it to one of the pages that can > > > > > > > appear there. Then onMouseovers in the links in the left frame > > > > > > > ("LeftNav") change the content of Main.
> > > > > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > > > > and does not pick up the results of the onMouseovers. It continues to > > > > > > > see just the initial empty page with its background.
> > > > > > > It does seem that FB can display the DOM for whatever is current > > > > > > > however,.- Hide quoted text -
I don't know why I saw it work in my version ... once. The frames business is pretty confusing, since documents don't have parentNodes, but really they do if they are in frames. Then there are contentDocuments, defaultViews, ownerDocuments, ... what a mess. All because some clever programmer decided to single the "top" of the DOM with parentNode == null and an even more clever fellow decided to embed documents in another DOM.
I think I am getting close. Next time I will test a couple of times first... John.
On Jul 16, 10:45 am, BobH <r.hassin...@ieee.org> wrote:
> I tracked down firebug-1.1eval.94.1.05.xpi and installed it on a new > download of FB 1.05 under FF 2.0.0.4 (e.g. apparently without > firebug-1.1eval.93.1.05.xpi - I don't know another way to undo that). > I tried it against the small test case and it still did not work > correctly. Would firebug-1.1eval.93.1.05.xpi be required, or is there > some other problem?
> BTW - I am not sure if I was clear about the multiple <HTML>s when > trying with FF 3. The frames case always shows an <HTML> for the > frame set and for each frame. What I noted was that <HTML>s seemed to > be accumulating - I think under one of the pages within the frameset > (although I don't recall exactly at this point).
> On Jul 16, 12:38 pm, John J Barton <johnjbar...@johnjbarton.com> > wrote:
> > Ok, I fixed it this time really ;-). I had the right problem but the > > wrong fix. Firebug has no representation for "document element", so > > when a mutateNode event comes in with the parentNode of document > > element, the representation cannot be updated. I inserted two lines: > > mutateNode: function(target, parent, nextSibling, removal) > > { > > if (parent.nodeType == 9) > > parent = parent.documentElement;
> > this.markChange(); > > to cause the parent to become the <html> element. Now the update shows > > up like any other node, highlighted in yellow etc.
> > I created a new release, firebug-1.1eval.94.1.05.xpi with just this > > update. In the process I discovered that Firebug blocks UI updated on > > FF3.0a6 when you refresh the page. So unfortunately this combination > > is not working yet. Hopefully the firebug-1.1eval.94.1.05.xpi will > > work in FF2; if you try it I would appreciate feedback.
> > John.
> > On Jul 15, 6:23 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > Yes it looks like my "fix" did not work. But I am puzzled by your > > > comment "I see multiple <html> s in the HTML display", because that is > > > what I saw when I thought it was fixed.
> > > I think the problem is in the html.mutateNode code, which is why the > > > initial display works, but the update does not. This code creates a > > > "parallel universe", a set of nodes to put in the HTML panel to > > > represent the user's DOM. For your test case, the process comes up > > > with a null box, hence no updates to the view.
> > > > Sorry to not know more about how all this works.
> > > > I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons > > > > now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement > > > > in the problem I am seeing on my site, nor do I see an improvement in > > > > the site athttp://users.rcn.com/ieeeworc/.
> > > > I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I > > > > can find to the FF3a5 that was mentioned. I don't see that the > > > > combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact > > > > that seems to be broken more (I see multiple <html> s in the HTML > > > > display, and the at least part of the time links don't seem to work.
> > > > On Jul 15, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> > > > > wrote:
> > > > > That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > > > > > The filter removes debug statements I need to work on the code. > > > > > I add stuff to this branch incrementally then move it on to branches/ > > > > > eval every couple of weeks. Then Xucia.com builds that branch for > > > > > you.
> > > > > > As a newcommer I am not familiar with the way all this works. I don't > > > > > > see where or what r66 is, and I don't know if I can take advantage of > > > > > > it now, or if the process is to wait for it to be incorporated into a > > > > > > new Firebug version.
> > > > > > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > > > > Fix is in r66 on branches/explore.
> > > > > > > The fix only deals with updates on document Node that are not the root > > > > > > > of the HTML view. I guess that is frames whose document is updated > > > > > > > wholesale.
> > > > > > > Firebug does not watch frames because it is intended to catch frame > > > > > > > updates via mutate events. But it missed one case: the update is the > > > > > > > whole frame document.
> > > > > > > Or so I guess. I don't really understand the DOM for frames.
> > > > > > > > Thanks John. Looks like a bit of a learning curve to really get into > > > > > > > > all that, which I will work on.
> > > > > > > > FWIW I did note around lines 393-411 a section that includes the > > > > > > > > comment:
> > > > > > > > // Only watch windows that are their own parent - e.g. not frames
> > > > > > > > and some commented out code. Maybe a clue?
> > > > > > > > It would be interesting to understand the reasons for that design.
> > > > > > > > I started looking for an easily viewed case that I am familiar with to > > > > > > > > try FB against a frames based page and noted the one here:
> > > > > > > > That is a fairly simple, but interesting case. There are four > > > > > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > > > > > the top level frameset initializes it to one of the pages that can > > > > > > > > appear there. Then onMouseovers in the links in the left frame > > > > > > > > ("LeftNav") change the content of Main.
> > > > > > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > > > > > and does not pick up the results of the onMouseovers. It continues to > > > > > > > > see just the initial empty page with its background.
> > > > > > > > It does seem that FB can display the DOM for whatever is current > > > > > > > > however,.- Hide quoted text -
ok, I think I got it this time. The html panel now watches embedded windows, eg inside frames. When they unload or load, the html panel simulates a mutation event at the top of the document to remove or add the <html> node.
The new version is up at http://fireclipse.xucia.com. I loaded it and checked that the html panel updates when both the test case in issue 239 is used and the Worchester County example with mouse over is used. Let me know it this solves your case as well.
John.
On Jul 16, 10:33 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> I don't know why I saw it work in my version ... once. The frames > business is pretty confusing, since documents don't have parentNodes, > but really they do if they are in frames. Then there are > contentDocuments, defaultViews, ownerDocuments, ... what a mess. All > because some clever programmer decided to single the "top" of the DOM > with parentNode == null and an even more clever fellow decided to > embed documents in another DOM.
> I think I am getting close. Next time I will test a couple of times > first... > John.
> On Jul 16, 10:45 am, BobH <r.hassin...@ieee.org> wrote:
> > I tracked down firebug-1.1eval.94.1.05.xpi and installed it on a new > > download of FB 1.05 under FF 2.0.0.4 (e.g. apparently without > > firebug-1.1eval.93.1.05.xpi - I don't know another way to undo that). > > I tried it against the small test case and it still did not work > > correctly. Would firebug-1.1eval.93.1.05.xpi be required, or is there > > some other problem?
> > BTW - I am not sure if I was clear about the multiple <HTML>s when > > trying with FF 3. The frames case always shows an <HTML> for the > > frame set and for each frame. What I noted was that <HTML>s seemed to > > be accumulating - I think under one of the pages within the frameset > > (although I don't recall exactly at this point).
> > On Jul 16, 12:38 pm, John J Barton <johnjbar...@johnjbarton.com> > > wrote:
> > > Ok, I fixed it this time really ;-). I had the right problem but the > > > wrong fix. Firebug has no representation for "document element", so > > > when a mutateNode event comes in with the parentNode of document > > > element, the representation cannot be updated. I inserted two lines: > > > mutateNode: function(target, parent, nextSibling, removal) > > > { > > > if (parent.nodeType == 9) > > > parent = parent.documentElement;
> > > this.markChange(); > > > to cause the parent to become the <html> element. Now the update shows > > > up like any other node, highlighted in yellow etc.
> > > I created a new release, firebug-1.1eval.94.1.05.xpi with just this > > > update. In the process I discovered that Firebug blocks UI updated on > > > FF3.0a6 when you refresh the page. So unfortunately this combination > > > is not working yet. Hopefully the firebug-1.1eval.94.1.05.xpi will > > > work in FF2; if you try it I would appreciate feedback.
> > > John.
> > > On Jul 15, 6:23 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > Yes it looks like my "fix" did not work. But I am puzzled by your > > > > comment "I see multiple <html> s in the HTML display", because that is > > > > what I saw when I thought it was fixed.
> > > > I think the problem is in the html.mutateNode code, which is why the > > > > initial display works, but the update does not. This code creates a > > > > "parallel universe", a set of nodes to put in the HTML panel to > > > > represent the user's DOM. For your test case, the process comes up > > > > with a null box, hence no updates to the view.
> > > > > Sorry to not know more about how all this works.
> > > > > I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons > > > > > now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement > > > > > in the problem I am seeing on my site, nor do I see an improvement in > > > > > the site athttp://users.rcn.com/ieeeworc/.
> > > > > I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I > > > > > can find to the FF3a5 that was mentioned. I don't see that the > > > > > combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact > > > > > that seems to be broken more (I see multiple <html> s in the HTML > > > > > display, and the at least part of the time links don't seem to work.
> > > > > On Jul 15, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> > > > > > wrote:
> > > > > > That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > > > > > > The filter removes debug statements I need to work on the code. > > > > > > I add stuff to this branch incrementally then move it on to branches/ > > > > > > eval every couple of weeks. Then Xucia.com builds that branch for > > > > > > you.
> > > > > > > As a newcommer I am not familiar with the way all this works. I don't > > > > > > > see where or what r66 is, and I don't know if I can take advantage of > > > > > > > it now, or if the process is to wait for it to be incorporated into a > > > > > > > new Firebug version.
> > > > > > > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > > > > > Fix is in r66 on branches/explore.
> > > > > > > > The fix only deals with updates on document Node that are not the root > > > > > > > > of the HTML view. I guess that is frames whose document is updated > > > > > > > > wholesale.
> > > > > > > > Firebug does not watch frames because it is intended to catch frame > > > > > > > > updates via mutate events. But it missed one case: the update is the > > > > > > > > whole frame document.
> > > > > > > > Or so I guess. I don't really understand the DOM for frames.
> > > > > > > > > Thanks John. Looks like a bit of a learning curve to really get into > > > > > > > > > all that, which I will work on.
> > > > > > > > > FWIW I did note around lines 393-411 a section that includes the > > > > > > > > > comment:
> > > > > > > > > // Only watch windows that are their own parent - e.g. not frames
> > > > > > > > > and some commented out code. Maybe a clue?
> > > > > > > > > It would be interesting to understand the reasons for that design.
> > > > > > > > > I started looking for an easily viewed case that I am familiar with to > > > > > > > > > try FB against a frames based page and noted the one here:
> > > > > > > > > That is a fairly simple, but interesting case. There are four > > > > > > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > > > > > > the top level frameset initializes it to one of the pages that can > > > > > > > > > appear there. Then onMouseovers in the links in the left frame > > > > > > > > > ("LeftNav") change the content of Main.
> > > > > > > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > > > > > > and does not pick up the results of the onMouseovers. It continues to > > > > > > > > > see just the initial empty page with its background.
> > > > > > > > > It does seem that FB can display the DOM for whatever is current > > > > > > > > > however,.- Hide quoted text -
That is looking good John on my initial tries on those test sites and on the main site I develop. I will beat on it as I work on the site and watch for less obvious issues.
Thanks!
On Jul 18, 12:49 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> ok, I think I got it this time. The html panel now watches embedded > windows, eg inside frames. When they unload or load, the html panel > simulates a mutation event at the top of the document to remove or add > the <html> node.
> The new version is up athttp://fireclipse.xucia.com. I loaded it and > checked that the html panel updates when both the test case in issue > 239 is used and the Worchester County example with mouse over is > used. Let me know it this solves your case as well.
> John.
> On Jul 16, 10:33 pm, John J Barton <johnjbar...@johnjbarton.com> > wrote:
> > I don't know why I saw it work in my version ... once. The frames > > business is pretty confusing, since documents don't have parentNodes, > > but really they do if they are in frames. Then there are > > contentDocuments, defaultViews, ownerDocuments, ... what a mess. All > > because some clever programmer decided to single the "top" of the DOM > > with parentNode == null and an even more clever fellow decided to > > embed documents in another DOM.
> > I think I am getting close. Next time I will test a couple of times > > first... > > John.
> > On Jul 16, 10:45 am, BobH <r.hassin...@ieee.org> wrote:
> > > I tracked down firebug-1.1eval.94.1.05.xpi and installed it on a new > > > download of FB 1.05 under FF 2.0.0.4 (e.g. apparently without > > > firebug-1.1eval.93.1.05.xpi - I don't know another way to undo that). > > > I tried it against the small test case and it still did not work > > > correctly. Would firebug-1.1eval.93.1.05.xpi be required, or is there > > > some other problem?
> > > BTW - I am not sure if I was clear about the multiple <HTML>s when > > > trying with FF 3. The frames case always shows an <HTML> for the > > > frame set and for each frame. What I noted was that <HTML>s seemed to > > > be accumulating - I think under one of the pages within the frameset > > > (although I don't recall exactly at this point).
> > > On Jul 16, 12:38 pm, John J Barton <johnjbar...@johnjbarton.com> > > > wrote:
> > > > Ok, I fixed it this time really ;-). I had the right problem but the > > > > wrong fix. Firebug has no representation for "document element", so > > > > when a mutateNode event comes in with the parentNode of document > > > > element, the representation cannot be updated. I inserted two lines: > > > > mutateNode: function(target, parent, nextSibling, removal) > > > > { > > > > if (parent.nodeType == 9) > > > > parent = parent.documentElement;
> > > > this.markChange(); > > > > to cause the parent to become the <html> element. Now the update shows > > > > up like any other node, highlighted in yellow etc.
> > > > I created a new release, firebug-1.1eval.94.1.05.xpi with just this > > > > update. In the process I discovered that Firebug blocks UI updated on > > > > FF3.0a6 when you refresh the page. So unfortunately this combination > > > > is not working yet. Hopefully the firebug-1.1eval.94.1.05.xpi will > > > > work in FF2; if you try it I would appreciate feedback.
> > > > John.
> > > > On Jul 15, 6:23 pm, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > > Yes it looks like my "fix" did not work. But I am puzzled by your > > > > > comment "I see multiple <html> s in the HTML display", because that is > > > > > what I saw when I thought it was fixed.
> > > > > I think the problem is in the html.mutateNode code, which is why the > > > > > initial display works, but the update does not. This code creates a > > > > > "parallel universe", a set of nodes to put in the HTML panel to > > > > > represent the user's DOM. For your test case, the process comes up > > > > > with a null box, hence no updates to the view.
> > > > > > Sorry to not know more about how all this works.
> > > > > > I found firebug-1.1eval.93.1.05.xpi and loaded into my 1.05. Add-ons > > > > > > now shows Firebug as 1.1eval.93.1.05. But I do not see an improvement > > > > > > in the problem I am seeing on my site, nor do I see an improvement in > > > > > > the site athttp://users.rcn.com/ieeeworc/.
> > > > > > I found "Gran Paradiso Alpha 6.exe" which seems to be the closest I > > > > > > can find to the FF3a5 that was mentioned. I don't see that the > > > > > > combination of it and firebug-1.1eval.93.1.05.xpi helps, and in fact > > > > > > that seems to be broken more (I see multiple <html> s in the HTML > > > > > > display, and the at least part of the time links don't seem to work.
> > > > > > > That branch is a filtered copy of another branch,https://fbug.googlecode.com/svn/branches/explore > > > > > > > The filter removes debug statements I need to work on the code. > > > > > > > I add stuff to this branch incrementally then move it on to branches/ > > > > > > > eval every couple of weeks. Then Xucia.com builds that branch for > > > > > > > you.
> > > > > > > > As a newcommer I am not familiar with the way all this works. I don't > > > > > > > > see where or what r66 is, and I don't know if I can take advantage of > > > > > > > > it now, or if the process is to wait for it to be incorporated into a > > > > > > > > new Firebug version.
> > > > > > > > On Jul 15, 1:09 am, John J Barton <johnjbar...@johnjbarton.com> wrote:
> > > > > > > > > Fix is in r66 on branches/explore.
> > > > > > > > > The fix only deals with updates on document Node that are not the root > > > > > > > > > of the HTML view. I guess that is frames whose document is updated > > > > > > > > > wholesale.
> > > > > > > > > Firebug does not watch frames because it is intended to catch frame > > > > > > > > > updates via mutate events. But it missed one case: the update is the > > > > > > > > > whole frame document.
> > > > > > > > > Or so I guess. I don't really understand the DOM for frames.
> > > > > > > > > > Thanks John. Looks like a bit of a learning curve to really get into > > > > > > > > > > all that, which I will work on.
> > > > > > > > > > FWIW I did note around lines 393-411 a section that includes the > > > > > > > > > > comment:
> > > > > > > > > > // Only watch windows that are their own parent - e.g. not frames
> > > > > > > > > > and some commented out code. Maybe a clue?
> > > > > > > > > > It would be interesting to understand the reasons for that design.
> > > > > > > > > > I started looking for an easily viewed case that I am familiar with to > > > > > > > > > > try FB against a frames based page and noted the one here:
> > > > > > > > > > That is a fairly simple, but interesting case. There are four > > > > > > > > > > frames. The lower right one "Main", starts empty, then an onLoad in > > > > > > > > > > the top level frameset initializes it to one of the pages that can > > > > > > > > > > appear there. Then onMouseovers in the links in the left frame > > > > > > > > > > ("LeftNav") change the content of Main.
> > > > > > > > > > The Firebug HTML display does not pick up the result of the onLoad, > > > > > > > > > > and does not pick up the results of the onMouseovers. It continues to > > > > > > > > > > see just the initial empty page with its background.
> > > > > > > > > > It does seem that FB can display the DOM for whatever is current > > > > > > > > > > however,.- Hide quoted text -
|
