Port latest changes to MOZ_CAN_RUN_SCRIPT from bug 1533293 and bug 1539356
Categories
(Thunderbird :: Upstream Synchronization, enhancement)
Tracking
(Not tracked)
People
(Reporter: jorgk-bmo, Unassigned)
References
Details
Attachments
(1 obsolete file)
+++ This bug was initially created as a clone of Bug #1536047 +++
In bug 1536047 we decorated nsMsgCompose::ConvertAndLoadComposeWindow() with MOZ_CAN_RUN_SCRIPT since it calls nsIEditor::SelectAll() which now has that attbibute. We also decorated its callers, nsMsgCompose::BuildBodyMessageAndSignature() and nsMsgCompose::InitEditor(), and we also had to mess with QuotingOutputStreamListener::OnStopRequest(). All that happened here:
https://hg.mozilla.org/comm-central/rev/58d5b2195fc8921d6ba17446806051c8ddd68047
Sadly that caused problems with JS Account since JS Account calls these functions without strong references. Despite some attempts to fix JS Account, we couldn't fix it quickly. Boris suggested to implement the minimal fix, just to fix and decorate nsMsgCompose::ConvertAndLoadComposeWindow() with MOZ_CAN_RUN_SCRIPT_BOUNDARY. That happened here:
https://hg.mozilla.org/comm-central/rev/b1b1782857a7dc2d0f8f0f3d29810eca9a05d06c
There was also a lot of noise in that bug, disabling and re-enabling static analysis and JS Account, but that's not relevant here.
Purpose of this bug here is to
a) fix compose like we already had it in rev 58d5b2195fc8921d6ba17446806051c8ddd68047
b) fix JS Account, some WIPs here: attachment 9051818 [details] [diff] [review] and attachment 9051830 [details] [diff] [review]
Over to you, Ben.
| Reporter | ||
Comment 1•6 years ago
|
||
In bug 1540398 we have another problem with nsMsgCompose::SetIdentity() which is marked as MOZ_CAN_RUN_SCRIPT_BOUNDARY now.
Comment 2•6 years ago
|
||
Note to self: The catch was that it was hard to change/annotate the jsaccount calls because they were all implemented by macros. See the NS_FORWARD_* macros, generated by xpcom/idl-parser/xpidl/header.py. If we can't get the macros to generated the code we need we'll have to expand them out by hand (probably not as bad as it seems - the interfaces involved don't change all that often...)
Comment 3•6 years ago
•
|
||
Note that I've made some changes to the analysis in bug 1536724 that should make it a bit simpler to do the forwarding bits. In particular, if you currently have:
NS_FORWARD_NSIFOO(mBar->)
where mBar is an nsCOMPtr<nsIFoo> then you should be able to replace it with:
NS_FORWARD_NSIFOO(nsCOMPtr<nsIFoo>(mBar)->)
And similar with a RefPtr<Bar> member:
NS_FORWARD_NSIFOO(RefPtr<Bar>(mBar)->)
In other words, option 2 from bug 1536047 comment 27 should now work fine for the mFakeThis bits.
| Reporter | ||
Updated•6 years ago
|
Updated•5 years ago
|
Updated•3 years ago
|
Comment 4•2 years ago
•
|
||
Upstream bug 1533293 and bug 1539356 have been fixed.
Updated•1 year ago
|
Description
•