|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Seems in EO 2015 the BeforeNavigate event is being raised from a worker thread. To your credit, that is documented as such now too.
But it is changed from before (2014 for sure, don't know if it started this way in 2015 or not) and causes me, and perhaps others some issues.
I'm particularly puzzled by this statement in the docs:
Note: This event is raised by an internal worker thread. You must return from your event handling code as fast as possible.
What does that mean, "as fast as possible"? What are the implications of not returning as fast as possible, here that make this noteworthy. I mean, that is kind of like stating the obvious.
Really, the point is, this is a significant API behavior change. I would say that it is a potentially breaking change that should be called out in a document that lists any such changes from prior versions. I don't see any such document. Is there one? There doesn't appear to be any mention of the BeforeNavigate event in the online changelog either, for that matter.
My real question is - are there any other cases where events are now fired on a different thread, or any other significant behavior changes to existing API methods or events, etc...
Thanks
roger
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
As far as I know this is the only one that has this kind of change. The change is due to a deadlock issue that was recently discovered that is unrelated to the 2015 release (which means that even if we had not released 2015 we would have had to make this change). The deadlock scenario involves a plugin making a call in the UI thread, which has a high probability of colliding with the BeforeNavigate event since this is also the time the plugin unloads for the previous page. When this occurs it can cause a deadlock scenario inside the browser engine. This deadlock scenario does not occur in the original chrome browser engine since it does not route any action through the UI thread. In order to resolve this issue, we had to move the event back to the IO thread. The fact that it is now in the IO thread means that it blocks all other IO operations in the browser engine. This is why the document explicitly mentioned that you must return from your event handling code as fast as possible --- for example, displaying a dialog asking user to continue or not would be a bad idea in this event. I apologize for the breaking change but please be rest assured that we are extremely careful when making this kind of changes as we do understand the implication of this kind of changes.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Thanks for the clarification.
fwiw - I have identified a different, (likely related) issue, for which i have submitted a test project via email.
will be following up with that soon, hopefully...
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Hey, so i submitted a test project via email, and got an initial confirmation that it was received.
That was over a week ago and i've heard nothing since, and have followed up a couple times via email asking for status.
I need to know if anybody is making any kind of progress on this or what.
Please follow up soon. The email subject line was "EO 2015 WebControl hangs when used from an Excel Addin project" and as far as i can tell, there is no other tracking info available for test project submission in that way.
Thanks.
roger
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
Hi,
I am really sorry about the delay. Unfortunately that is still sitting in our queue. Currently we have a blocking issue that we are trying to work out --- as soon as we work out that one we will look into the Excel AddIn issue. We are aware that you had this issue before and we are trying to get it resolved as soon as possible. Hopefully we will be able to get back to you early next week.
Thanks!
|
|
Rank: Advanced Member
Groups: Member
Joined: 3/11/2014
Posts: 57
|
Ok, thanks for the update.
I'll follow up again next week sometime.
|
|
Rank: Advanced Member
Groups: Member
Joined: 12/1/2014
Posts: 57
|
This change creating a problem for me as well so I moved my code to the BeforeRequestLoad event. This seems to work.
|
|
Rank: Administration
Groups: Administration
Joined: 5/27/2007
Posts: 24,229
|
yvesm wrote:This change creating a problem for me as well so I moved my code to the BeforeRequestLoad event. This seems to work. Yes. BeforeRequestLoad would be a good alternative since it's still fired in the main thread. However please keep in mind that beforeRequestLoad is fired for every request, not just once for the whole page. Thanks!
|
|