WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED INVALID
29142
timing issue with calling the InjectedScript stuff early
https://bugs.webkit.org/show_bug.cgi?id=29142
Summary
timing issue with calling the InjectedScript stuff early
Patrick Mueller
Reported
2009-09-10 12:59:40 PDT
I'm working on
bug 27514
, and during the early processing of this code, am trying to call out to some of the InjectedScript calls, for instance WebInspector.console._evalInInspectedWindow(). While I don't get an error from making these calls, I'm also not getting any callbacks invoked. I haven't tried, because I don't know the ramifications, but am wondering if moving <script type="text/javascript" src="InjectedScript.js"></script> <script type="text/javascript" src="InjectedScriptAccess.js"></script> from near the bottom of inspector.html to somewhere higher (like, really high), would help. For now, I've rigged my code to lazily make the calls, so the calls happen after everything has been set up or has settled down. But lazily means not showing the user some details I should be able to show them. If moving the code up can't be done, then it would be nice to have an event dispatched that we can listen for when the subsystem has been initialized. Alternatively, perhaps the code could be rigged to save the requests made before things are set up, and then run them itself when it's ready. I don't really care WHEN the subsystem becomes available, but I do need a way to use it and know I will get responses back.
Attachments
Add attachment
proposed patch, testcase, etc.
Timothy Hatcher
Comment 1
2009-09-10 13:24:19 PDT
I think moving them to be one of the first scripts makes sense. You should try it out.
Pavel Feldman
Comment 2
2009-09-11 06:45:56 PDT
Order is very unlikely to be a problem. It only matters when you do eval _before_ onload handler. That is not the way we act in the frontend. Otherwise all the scripts are already loaded. You are saying callback is not invoked, but does the actual action get control flow? Try dumping into console from InjectedScript's eval to see if the control reaches that point.
Patrick Mueller
Comment 3
2009-09-11 07:55:41 PDT
I figured the <src script=> order didn't matter, having this keyed off of on onload handler makes more sense. Still a problem - how can I properly hook this? Even if there is a guaranteed dispatch order (order of registration) for event handler), I would need to register AFTER yours. No way for me to know that. I think you need to add an event ala the WI.Object event dispatch stuff to let us know when it's safe to call this stuff. It would make it much clearer anyway. Rather that subclass that class, I'd likely just create an eventManager object as an instance of that class, and write cover methods that invoked the Object methods. w/r/t what happened; I didn't debug into it. I made the call, but never got the callback. Later execution of the same code (after load, presumably), callback gets invoked fine. Whether or not the code I requested be run - just an eval to get the value of the watch expression, dunno.
Timothy Hatcher
Comment 4
2009-09-11 17:51:47 PDT
Do you know where you are calling it early?
Patrick Mueller
Comment 5
2009-09-11 19:44:16 PDT
(In reply to
comment #4
)
> Do you know where you are calling it early?
Since this was in bring-up code, was a bit difficult to tell what was going on. I believe I put a logging statement in WatchExpressionsSidebarPane.js, in the appendResult() callback inside WatchExpressionsSection.prototype.update(). I could see WebInspector.console._evalInInspectedWindow() was getting called, but the callback never got invoked. The reason this is being called early is that the Watch Expressions were attempting to be evaluated so they could be displayed immediately as the Scripts panel was open. To work around this, the Watch Expressions pane is now always not-expanded when the Scripts panel open, and expanding the section causes an explicit refresh, so there's a built-in human-based delay. Fine for now, but it still seems to me that we need an event when the InspectedScript stuff is ready, or it needs to queue up requests and act on them when it becomes ready.
Timothy Hatcher
Comment 6
2009-09-11 19:51:45 PDT
I see. I like the queue idea.
Timothy Hatcher
Comment 7
2009-09-11 19:52:26 PDT
You can also refresh when the reset function on the Panel is called. That should be at a good time.
Blaze Burg
Comment 8
2014-01-26 19:06:37 PST
Not sure if relevant anymore. Re-open if necessary.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug