1231753 - Abort JS Execution after Prerendering-BlackListed API is Called.

Status: RESOLVED DUPLICATE of bug 1069719

(Core :: DOM: Core & HTML, defect)

Comment 1

[Hsin-Yi Tsai (she/her) (REO Fx 129) [:hsinyi]]

Hi Ehsan,
This is the task about js execution abortion for blacklist APIs we talked today in Mozlando session. Would be great if you could fill in more details here. Thank you!

Comment 2

[(no longer active)]

See the JS_SetInterruptCallback() API.  The trick here is to trigger an interrupt when a blacklisted function is called through JS_RequestInterruptCallback().  When that happens, the callback must return false in order to abort script execution.

Comment 3

[Bevis Tseng[:bevis][:btseng](Exited)]

Take this bug to follow up.

Comment 4

[Bevis Tseng[:bevis][:btseng](Exited)]

I'd like to update the title more properly for the task to be done in this bug after recapping the whole story of the blacklist for prerendering in these 2 days. :p

The extended attribute of |UnsafeInPrerendering| has been defined in bug 1038993 to allow the api to be identified in the blacklist.
In addition, in bug 1069719, the implementation of throwing an uncatchable exception, when blacklisted function is invoked, was done as well.

However, this exception just prevent the execution of single event that invokes the blacklisted function the JS engine will keep running the next task in the queue which is not necessary anymore after a blacklisted function is called.

Hence, I expect that this bug is the follow-up of bug 1069719 comment 4 to request the JS engine to abort for the tasks that already inserted in the event queue.

Hi Ehsan,

Did I miss something that was not covered in this bug as mentioned above?
In addition, it seems to be done originally in bug 1069719 but was removed from bug 1069719.
Does that mean JS_SetInterruptCallback/JS_RequestInterruptCallback is not the right way to go?

Comment 5

[(no longer active)]

(In reply to Bevis Tseng[:bevistseng][:btseng] from comment #4)
> I'd like to update the title more properly for the task to be done in this
> bug after recapping the whole story of the blacklist for prerendering in
> these 2 days. :p
> 
> The extended attribute of |UnsafeInPrerendering| has been defined in bug
> 1038993 to allow the api to be identified in the blacklist.
> In addition, in bug 1069719, the implementation of throwing an uncatchable
> exception, when blacklisted function is invoked, was done as well.

Ah, right!  I was trying to find this code at the face to face discussion in Orlando, thanks for digging it up!  So this part is done.  Good!

> However, this exception just prevent the execution of single event that
> invokes the blacklisted function the JS engine will keep running the next
> task in the queue which is not necessary anymore after a blacklisted
> function is called.

Hmm can you give an example please?  HandlePrerenderingViolation() is supposed to prevent this, but it's possible we need to do more there?

> Hence, I expect that this bug is the follow-up of bug 1069719 comment 4 to
> request the JS engine to abort for the tasks that already inserted in the
> event queue.

Not sure if I follow.  The patch you're referring to never landed!

> Hi Ehsan,
> 
> Did I miss something that was not covered in this bug as mentioned above?
> In addition, it seems to be done originally in bug 1069719 but was removed
> from bug 1069719.
> Does that mean JS_SetInterruptCallback/JS_RequestInterruptCallback is not
> the right way to go?

I think this is really just a dupe of bug 1069719, I just didn't remember that I had finished that part.  :-)  Unless if you have examples that show this is insufficient as I asked above.

Thanks!!

Comment 6

[Bevis Tseng[:bevis][:btseng](Exited)]

(In reply to :Ehsan Akhgari from comment #5)
> > However, this exception just prevent the execution of single event that
> > invokes the blacklisted function the JS engine will keep running the next
> > task in the queue which is not necessary anymore after a blacklisted
> > function is called.
> 
> Hmm can you give an example please?  HandlePrerenderingViolation() is
> supposed to prevent this, but it's possible we need to do more there?
> 
You are right, I have the same understanding with yours after further review of current implementation in these 2 days.
> > Hence, I expect that this bug is the follow-up of bug 1069719 comment 4 to
> > request the JS engine to abort for the tasks that already inserted in the
> > event queue.
> I think this is really just a dupe of bug 1069719, I just didn't remember
> that I had finished that part.  :-)  Unless if you have examples that show
> this is insufficient as I asked above.
> 
Thanks for the clarification.
I'll mark this as dupe of bug 1069719. :)