Open Bug 1431059 Opened 4 years ago Updated 4 years ago

Cursor is relocated after NotifyComposeBodyReady event

Categories

(Thunderbird :: Message Compose Window, defect)

58 Branch
defect
Not set
normal

Tracking

(Not tracked)

People

(Reporter: realRaven, Unassigned)

Details

Attachments

(1 file)

In Thunderbird 58b2 the cursor is force located to the top of the email _after_ the NotifyComposeBodyReady event. This prevents my add-on (SmartTemplate4) and others (Stationery) of setting the cursor location as configured by our users via cursor variables / cursor html nodes.

See also:
https://www.mozdev.org/bugs/show_bug.cgi?id=26465 

while debugging with SmartTemplate version 1.5 prerelease 145 I saw my cursor moved correctly during my NotifyComposeBodyReady handler. Then the cursor is relocated after.

Note: my implementation calls gMsgCompose.editor.resetModificationCount() at the end.

For reproducing, you can install the attached prerelease of SmartTemplate4, then configure the reply template as follows:

=======test<br>
<p>Dear %cursor%,</p>
=======test<br>

this should show the cursor in the empty paragraph when replying to an email. For helpful breakpoints, you can set configuration 

extensions.smartTemplate4.debug.composer = true
When forwarding or replying, the focus should be in the body of the email, but it is somewhere else on the compose window.  I can use Shift+Tab to get the cursor where it should be.  My template uses the %cursor% code in it.  This was not a problem with TB 52.

My other limited add-ons are: MinimizeToTray revived (MinTrayR); Open With; QuickFolders; Restart Thunderbird; and Xpunge.  I've used them all together without issues for a long time and after disabling them all except SmartTemplate4, the issue still persists.  When I disable SmartTemplate4, the cursor is in the expected location.
 (In reply to Noah from comment #1)
> When forwarding or replying, the focus should be in the body of the email,
> but it is somewhere else on the compose window.  I can use Shift+Tab to get
> the cursor where it should be.  My template uses the %cursor% code in it. 
> This was not a problem with TB 52.
> 
> My other limited add-ons are: MinimizeToTray revived (MinTrayR); Open With;
> QuickFolders; Restart Thunderbird; and Xpunge.  I've used them all together
> without issues for a long time and after disabling them all except
> SmartTemplate4, the issue still persists.  When I disable SmartTemplate4,
> the cursor is in the expected location.

Make sure to retest with the the attached version (prerelease 145) which deals with all the changes in the latest code base. single stepping through the code using Tb58b3 on Windows7 demonstrates that the cursor is set correctly at first, but it may be different your system.
Axel - Just installed on TB58b3, Windows 10 (7 wasn't an option on your site) and still the focus is not correct.  For each of forward, reply, reply-all and new message, the focus seems not to be on anything type-able.  When I tab 4 times, I can now start to enter an email address.  When tabbing into the body section, the cursor is in the location as defined by %cursor%.  Also note that 1 shift+tab puts the cursor into the body of the email in the correct place.  I disabled applying the template to the emails and the same issue is persistent.

I can't figure out where the cursor want's to be, but it seems to be the same area as when you shift+tab through past the "From" area and before you get back to the body of the email.
(In reply to Axel Grude [:realRaven] from comment #0)
> In Thunderbird 58b2 the cursor is force located to the top of the email
> _after_ the NotifyComposeBodyReady event.
Well, that all depends on whether it's a new message or a reply and what the user has configured. For a new message in paragraph mode TB's NotifyComposeBodyReadyNew() does position at the top into the paragraph:
https://searchfox.org/comm-central/source/mail/components/compose/content/MsgComposeCommands.js#441
And that hasn't changed since TB 52:
https://dxr.mozilla.org/comm-esr52/source/mail/components/compose/content/MsgComposeCommands.js#395

> while debugging with SmartTemplate version 1.5 prerelease 145 I saw my
> cursor moved correctly during my NotifyComposeBodyReady handler. Then the
> cursor is relocated after.
Which handler runs first, yours or the TB one?

I don't think we have time to debug your add-on or with your add-on.
(In reply to Jorg K (GMT+1) [Very limited availability 18-22 Jan 2018] from comment #4)
> (In reply to Axel Grude [:realRaven] from comment #0)> 
> > while debugging with SmartTemplate version 1.5 prerelease 145 I saw my
> > cursor moved correctly during my NotifyComposeBodyReady handler. Then the
> > cursor is relocated after.
> Which handler runs first, yours or the TB one?

therein lies the rub. How do I make sure mine is last? My guess is that the calling behavior has changed.

window.setTimeout ( function() {
  let util = SmartTemplate4.Util,
      logDebugOptional = util.logDebugOptional.bind(util);
	SmartTemplate4.init();
	// the starting point of this listener which is triggered by composer, is defined in smartTemplate-main.js
  logDebugOptional('composer', "Adding initListener for msgcomposeWindow...");
  let composer = document.getElementById("msgcomposeWindow");
  composer.addEventListener("compose-window-init", SmartTemplate4.initListener, false);
},10 );

within initListener() I do:

gMsgCompose.RegisterStateListener(SmartTemplate4.stateListener);

can I somehow postpone registering my listener somehow pending on the Thunderbird Core Listener (e.g. using promises)? Or is there another way to ensure this?


> 
> I don't think we have time to debug your add-on or with your add-on.
no worries, I am trying as best myself.
Any progress on this?
I made a workaround in SmartTemplate 1.5.1 by  forcing the focus back into its designated field

(into BODY when replying)
(into "To:" address widget when composing new and forwarding)
Using SmartTemplate 1.5.0 or 1.5.1, when I start a new text the cursor defaults to the end of the Reply-To field. 

I just upgraded to Ubuntu 18.04 (TB 52.7.0), and since then this behavior consistently occurs, even with all other add-ons disabled.
Please try:
https://www.mozdev.org/bugs/show_bug.cgi?id=26465
and add your observations and EXPECTED BEHAVIOR there.
You need to log in before you can comment on or make changes to this bug.