On Nov 26, 6:45 am, Jan Odvarko <[EMAIL PROTECTED]> wrote:
...
> So, at the time when http-on-modify-request event is fired, the
> current window is still associated with a context (which is, as you
> saying the previous one).
> ...
Maybe this is a blessing in disguise? One of our other problems is the
mismatch between the page-oriented debugging model of Firebug and the
application-oriented model of Web 1.0 applications. We currently have
poor support for a page that replaces itself with another page from
the same 'application'.
>
> You can clearly see that the previous context (softwareishard.com) is
> destroyed *after* the new page (google.cz) started to load. Also the
> new context is initialized (initContext) after the http-on-* events.
> All the other page requests (logo_plain.png, etc.) are done properly
> when the new context (google.cz) is ready to be used. But the first
> document request is done to early.
> ...
What if we attached the http-on-* event results to which ever context
it maps to, then when we get the initContext we attempt to analyze
whether this request is a new app or not. We could make this
explicit, and for the new page we issue "reInitContext(context,
oldURL, newURL)" rather than destroyContext and initContext. Then
reInitContext can be in charge of moving pre-destroyContext info into
the right places for the new page.
jjb
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Firebug" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/firebug?hl=en
-~----------~----~----~----~------~----~------~--~---
