Open Bug 1536535 Opened 6 years ago Updated 1 year ago

Port latest changes to MOZ_CAN_RUN_SCRIPT from bug 1533293 and bug 1539356

Categories

(Thunderbird :: Upstream Synchronization, enhancement)

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.

Flags: needinfo?(benc)

In bug 1540398 we have another problem with nsMsgCompose::SetIdentity() which is marked as MOZ_CAN_RUN_SCRIPT_BOUNDARY now.

Summary: Port latest changes to MOZ_CAN_RUN_SCRIPT from bug 1533293 - take 2 → Port latest changes to MOZ_CAN_RUN_SCRIPT from bug 1533293 and bug 1539356

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...)

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.

Flags: needinfo?(benc)
Component: General → Upstream Synchronization
Product: MailNews Core → Thunderbird
Severity: normal → S3

Upstream bug 1533293 and bug 1539356 have been fixed.

Attachment #9384177 - Attachment is obsolete: true
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: