Refreshing HTML

[BobH]

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.

Bob

[John J Barton]

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.

[BobH]

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:

[John J Barton]

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.

[BobH]

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.

[David Zechiel]

Here's the situation that is bedeviling me:

I load a page with a call like "https://localhost/cgi-bin/slmcore?
view=10&tab=0".

This page has a form like:

<form method="post" name="main" onsubmit="return validateForm(this)">
.
.
</form>

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.

Has anyone else seen this behavior?

Thanks,

David Zechiel

[BobH]

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).

[John J Barton]

All of the code for noticing change in pages is in this file for 1.05:
http://fbug.googlecode.com/svn/trunk/content/firebug/tabWatcher.js
or for my version:
http://fbug.googlecode.com/svn/branches/explore/content/firebug/tabWatcher.js

[BobH]

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:

http://users.rcn.com/ieeeworc/

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,.

[John J Barton]

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.

[BobH]

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.

> > however,.- Hide quoted text -
>
> - Show quoted text -

[John J Barton]

The built version just updated on Xucia.com:
http://groups.google.com/group/firebug/browse_thread/thread/33a17ccdd6ecfe27

The "R66" means revision 66 of the source tree at https://fbug.googlecode.com/svn/.

The built version is from one part or 'branch' of the source tree:
https://fbug.googlecode.com/svn/branches/eval
This my proposed v1.1 of Firebug.

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.

The other branch of the tree is
https://fbug.googlecode.com/svn/trunk
It contains v1.05, the stable version on http://getfirebug.com

More hints:
http://fbug.googlecode.com/svn/branches/explore/Readme.txt
To build the source you need Subversion, Ant, and if you want to
filter to create eval, cygwin or linux.

John.

[BobH]

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 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:
> The built version just updated on Xucia.com:http://groups.google.com/group/firebug/browse_thread/thread/33a17ccdd...
>
> The "R66" means revision 66 of the source tree athttps://fbug.googlecode.com/svn/.

>
> The built version is from one part or 'branch' of the source tree:https://fbug.googlecode.com/svn/branches/eval
> This my proposed v1.1 of Firebug.
>

> 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.
>

> The other branch of the tree ishttps://fbug.googlecode.com/svn/trunk
> It contains v1.05, the stable version onhttp://getfirebug.com

[BobH]

I have posted this in fbug (239) with as a simple a test as I can
think of.

It is at http://eisner.decus.org/~hassinger/frame_test/TEST_FRAMESET.HTML

On Jul 15, 5: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/.

[John J Barton]

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/.

[John J Barton]

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.

[BobH]

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>

[John J Barton]

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.

[John J Barton]

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>

[BobH]

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