1043784 - after confirming autocomplete suggestion with TAB key combination, Thunderbird adds a new addressing line, does not move focus to the subject text box

Status: RESOLVED FIXED

(Thunderbird :: Message Compose Window, defect)

Description

[Attila Hammer]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0 (Beta/Release)
Build ID: 20140715214335

Steps to reproduce:

After CTRL+N keystroke when the typed search term resulting correct autocompleted e-mail address from address book, TAB and SHIFT+TAB keystrokes resulting present a new to: text box.


Actual results:

Expected result before Thunderbird 31.0:
Previous versions after CTRL+N keystroke when a search term resulting correct autocompleted e-mail address, if the user press TAB and SHIFT+TAB keystrokes, Thunderbird right jump the Subject text box or the previous address type combo box with possible set address type (to: CC, BCC, etc).
Of course, if in to: text box after autocompletion the user press ENTER key, right to presenting a new to: text box.
I using Thunderbird with screen reader and now more time happening me to I type the subject with the new to: text box (more time forgot with subject text box need pressing two TAB keys). :-):-)

Comment 1

[Attila Hammer]

With Thunderbird 33.0a2 and 34.0A1 version affected too, I downloaded following place the test version:
ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-aurora/thunderbird-33.0a2.en-US.linux-i686.tar.bz2
ftp://ftp.mozilla.org/pub/thunderbird/nightly/latest-comm-central/thunderbird-34.0a1.en-US.linux-i686.tar.bz2

Comment 2

[Attila Hammer]

Attachment: Video to show the issue with various situations

This video shows the issue with various situations.
When first time pop up the message dialog, I simple typed an e-mail address.
After this, press SHIFT+TAB keystroke. Ideal situation possible setting the typed e-mail address type with any type (to:, CC, bcc). Now, the caret land the new empty to: field. So, I need pressing three SHIFT+TAB keystrokes to change the first e-mail address type with bcc or cc type, and after this, need jumping more tab keys the subject field.

The second case simple typed an e-mail address, and two keypress need using to jump the subject field.

Attila

Comment 3

[Anton Derbenev]

just checked. Confirm.

Comment 4

[Peter Lairo]

Just to clarify the expected results a bit:

1. Tab should put the selection in the *Subject* line (and not create a new To/CC/BCC address line).

2. Shift+Tab should put the selection on the To/CC/BCC drop-down-button *before* the current address.

Comment 5

[Attila Hammer]

Peter, correct with you wrote. This is the expected result with need restore if this is possible.
Possible fixing this issue both Thunderbird 31.0 and 33X/34.x releases?

Attila

Comment 6

[Wayne Mery (:wsmwk)]

If it started in version 31, this is also regression of bug 959209

Comment 7

[Magnus Melin [:mkmelin]]

Modifying summary (tab-shift works like before afaikt), and confirming for discussion. 
This change was discussed in bug 959209 comment 6. I'm not sure I'd consider it a bug, but I'm open for arguments.

Comment 8

[Magnus Melin [:mkmelin]]

Attachment: bug1043784_tab_adds_address_row.patch

Restore the earlier behavior of not adding an addressing row when tabbing or selecting from autocomplete, but only for ENTER.

Comment 9

[Hungerburg]

Just FYI, tab in To: goes to Subject: when autocomplete fails (which happens in TB 31 rather often, autocomplete seems to have become slower, or am I dreaming?) It is only afer autocmplete, that tab creates another To: -- still, the subject of this report holds, so maybe I am preaching to the choir…

Comment 10

[Peter Lairo]

(In reply to Magnus Melin from comment #7)
> tab-shift works like before afaikt

No, it does not. Shift+Tab used to put the selection on the To/CC/BCC drop-down-button before the current address. 

This was very useful because when entering an address, one presses ENTER, and the selection goes to the next address line. After selecting the second address, being able to press Shift-Tab to change the To/CC/BCC is VERY useful because the second recipient is often a CC, and the third recipient is often myself (a BCC). Please fix this frustrating regression (and re-fix the Subject of this bug).

Comment 11

[Magnus Melin [:mkmelin]]

(In reply to Peter Lairo from comment #10)
> (In reply to Magnus Melin from comment #7)
> > tab-shift works like before afaikt
> 
> No, it does not. Shift+Tab used to put the selection on the To/CC/BCC
> drop-down-button before the current address. 

It does work like that for me (on linux), so I'm not sure what you're seeing.

Comment 12

[Peter Lairo]

On Windows 7:
1. type part of a name
2. select one of the matches via keyboard up/down arrows (or just accept the default selection)
3. Press SHIFT+Tab

Actual Result:
- A new address line is created, and the cursor is placed in it (the selection moves *forward*).

Expected Result:
- The selection should move *back* to the To/CC/BCC button of the address that was just selected.

Comment 13

[Magnus Melin [:mkmelin]]

Oh I see what you mean now (you mean during the selection process, before a new row was added). The patch (attachment 8463013 [details] [diff] [review]) fixes that, it's just a side effect of adding the row.

Comment 16

[Thomas D. (:thomas8)]

At second thoughts, I'm not very convinced of the behaviour proposed in this bug, although I do sympathise with its purpose of streamlining the tab circle for this particular scenario (so I'm a bit in between, no too strong feelings about this so far...). So I'm offering some thoughts for wontfix.

Please note that all of these problems will go away with the new recipient area design per bug 440377.

Behaviour proposed by this bug:
If we ignore the old behaviour (whatever it was), currently as of TB 31 this bug wants to remove the tab stop at the empty addressing line which follows the user-filled addressing lines (or to not even create that empty line at all when you confirm an autocomplete entry with tab).

Alternative behaviour proposed by me:
Instead, I propose that we keep the tab stop at the empty addressing line, and pressing tab again on the empty line then moves to subject (one extra stop, as in current TB 31). Here's why I think this is better:

1) We already have a potentially unlimited number of tabstops for every filled address line - just one more for the blank line doesn't really hurt, but it's actually quite useful (more below).

2) Given 1) where tab goes through each and every filled address line, it really comes as a surprise that the empty line, the only UI element where you are supposed to enter more addresses, is skipped - in fact, that's almost an accessability issue (because tab is the fine-grained focus circle that shouldn't skip anything relevant). And I think in both old and current design, we always try to keep one empty line to show users where the next address must go (as long as we still have this old and clumsy recipient area design).

3) Major point: If there's no tab stop at the empty line (or we don't even create an empty line), what are keyboard user's alternatives to get there after the fact?

Suppose I'm already in subject and forgot another recipient which I want to add now. Suppose the blank recipient line is already there because I used Enter before.

- Current behaviour (TB31) = my proposal: Shift+Tab (back to the empty recipient line), start typing recipient. Easy.
Current focus ring: Filled address line 1 > ... > Last Filled address line >
                    Blank address line > Subject

- Behaviour after this bug: Shift+Tab (back to the last filled recipient line because we didn't add a blank line), and then what? (intuitive try: TAB! - fails after this bug)
Proposed focus ring: Filled address line 1 > ... > Last Filled address line >
                     Subject

Same for forward tab cycle: Start out somewhere, tab forward until you are on the last filled address line, and then what? (intuitive try: TAB! - fails after this bug)

So the only way to get into the blank line, or add a blank line at all, is to somewhat unintuitively use ENTER on an already existing and confirmed address line. Why should I have to do that? There's nothing to confirm, and I'll actually be afraid that re-confirming with ENTER might somehow change my existing entry (you never know with autocomplete). I think that odd feeling is because the intuitive way of moving focus around across existing things without touching anything is TAB, not ENTER...

4) I can't think of external UX we can compare with; but my feeling is that TAB is a reasonably intuitive way of confirming things AND moving to the next element (in command prompts, tab even just completes the entry). Both before and after this bug, TAB will serve to confirm the selected autocomplete entry. Surprisingly, after this bug, one way of confirmation will create a new line (Enter), but the other one won't (Tab). And, per 1) and 2), the next relevant element here seems to be that single blank line (after all the filled lines)...

On the downside, my proposal will rob advanced users of the opportunity of NOT creating a blank line when they are done with addressing, and require one extra tab IF user is done with addressing. But do we have a safe way of telling if he's really done or he just wants to get out of the dropdown and confirm the autocompletion with tab?

Comment 17

[Thomas D. (:thomas8)]

TL;DR of comment 16:

The "blank recipient line" after filled recipient lines is an important UI element because it's the default way of adding new recipients.

Therefore:
- blank line should always be created after confirming an address (regardless if confirmation occurs with TAB or ENTER)
- blank line should always be a tab stop

To be consistent, I think my proposal also requires that when you just enter a new address manually, say you just type 'Peter <[e-mail]>', then press TAB, we should first create a new blank address line, then the next TAB goes into subject.

Imo the new flat design which emphasises the single-line address input fields even more than before (by white background on focused line) actually supports the notion of each line being an UI element in its own right (at editing time). Whereas before the new design, it looked more like a single notesheet where you just enter multiple lines with Enter. Iow, users might be MORE likely to use tab for just getting into the next (blank) line with our new design.

Comment 18

[Charles]

(In reply to Thomas D. from comment #16)
> At second thoughts, I'm not very convinced of the behaviour proposed in this
> bug, although I do sympathise with its purpose of streamlining the tab
> circle for this particular scenario (so I'm a bit in between, no too strong
> feelings about this so far...). So I'm offering some thoughts for wontfix.
> 
> Please note that all of these problems will go away with the new recipient
> area design per bug 440377.

Well... I guess that depends (lots of complex descriptions of behavior in there but I couldn't work out exactly what the final result would be)...

I actually like the old/original behavior, and I won't - or will only very rarely - put multiple addresses on one line.

I have no problem with, and agree that Thunderbird should fully support multiple addresses per line like all other email apps do, but there is no reason we can't have both the old behavior and the new.

They are really two totally different issues anyway.

The old behavior used ENTER to add a new address line, and TAB to go to the SUBJECT field.

Old way:

1. Add addresses
2. When done, TAB to subject field

Now with the bug:

1. Add addresses
2. Hit TAB
3. Hit DELETE to delete the blank line (I don't like it, it just looks wrong to me, and if I needed another one, I just clicked at the end of the last one and hit ENTER)
4. Hit TAB again to go to the Subject field

Note: I guess I would be fine with this bug being amended such that hitting TAB adds a blank address line BUT still just jumps straight to the Subject field instead of having to hit TAB again.

Reason: I am constantly entering something in the address field meant for the subject, then encounter an error when sending. It is extremely annoying.

Again - there is no reason that I can see to force us to have to hit TAB twice.

So:

Hit TAB - add blank address line AND jump to subject field
Hit ENTER, go to another address field.

Comment 19

[Thomas D. (:thomas8)]

More context (looking at FF and other spots in TB): Bug 97918, Bug 520040, ...

Comment 20

[Peter Lairo]

(In reply to Thomas D. from comment #16)

Although I disagree that TAB should add and enter a new address line (because it doubles the number of key-presses needed to finish entering an address, and ENTER already adds a new address line), I can see the reasoning for it (the edge case of a novice user NOT using their mouse for everything).

My main issue right now is that SHIFT+TAB doesn't go to the To/CC/BCC button BEFORE the current address anymore.

Comment 21

[Attila Hammer]

+1, SHIFT+TAB need jumping back the address type combo box, not adding a new address field.
For example I better would like to TAB key not add a new address field after typed the autocompleted e-mail address, similar if a typed full new e-mail address not have in the address book.
Now, tab key navigation not working consistent in Thunderbird 31.0 and higher development versions message compose window.
For example if I typing an e-mail address with not have in the address book and press TAB key, the caret correct jumping the subject field. This is the expected result both autocompleted e-mail addresses and in address book not have e-mail addresses.
SHIFT+TAB key combination works good, after I typed the e-mail address with not have in the address book and press SHIFT+TAB key combination, the caret jumps to the address type combo box.
This is the expected result with autocompleted e-mail addresses too.

Please not give won't fix flag this problem if this is possible.

Attila

Now happening following thing if for example typed the second e-mail address and want changing the address type:
1. Press SHIFT+TAB key.

Comment 22

[Attila Hammer]

I forgot a thing:
If more e-mail addresses is typed, after the last e-mail address need landing the caret with the subject field and not create a new address edit field.
Between typed e-mail addresses SHIFT+TAB key combination need switching the address type combo box and the previous typed address.
Peter, if need, please complete my two comments, possible my english language descriptions is not always good.

Attila

Comment 23

[Charles]

(In reply to Peter Lairo from comment #20)
> My main issue right now is that SHIFT+TAB doesn't go to the To/CC/BCC button
> BEFORE the current address anymore.

(In reply to Attila Hammer from comment #21)
> +1, SHIFT+TAB need jumping back the address type combo box, not adding a new
<snip>
> Please not give won't fix flag this problem if this is possible.

Guys... that is a DIFFERENT bug... related, maybe, but still different.

Please create/open a NEW bug for it.

Comment 24

[Attila Hammer]

Charles, the SHIFT+TAB related issue I reported with separate report in bug 1051564 and wrote two testcases with shows the different working method.
The tab key related issue and inconsistency possible fixing in 31.0 and higher development versions?
Two testcases, first testcase reproducing the problem:
1. Press CTRL+N keystroke.
2. Type an e-mail address with have your address book.
3. Press TAB key.
Expected result:
Caret need jumping the subject text box and not adding an empty address type.
Actual result: presenting a new empty to: text box. Second tab key jumping the subject text box.

Second testcase shows what happening if an e-mail address not have the address book:
1. Press CTRL+N keystroke.
2. Type [e-mail] address.
3. Press TAB key.
This situation the caret jumps correct with the subject line and Thunderbird correct not adding an empty to: text box.

For example with screen reader users important the consistent working method.

Attila
Attila

Comment 25

[Brian Norris]

While I read and understand Thomas D.'s comments about how TAB should create a new 'To' box, I respectfully disagree. I believe this issue is purely a regression and should be fixed to retain the old behavior. AFAICT, there was never a conscious UI decision to change the long-standing behavior of Thunderbird's compose window in this case, and so it should go through a proper UI review if it's going to be changed.

Additionally, the current behavior is extremely inconsistent. If I type an address that is NOT in my autocomplete list, then TAB still works like it used to. I see this as yet another sign that this is a regression, not an intentional change.

So please, let's consider this report a regression and get it fixed as such. This issue has seriously annoyed me (and presumably others on this ticket), and I'm just happy to find that someone else cared enough to report it already.

Thanks!

Comment 26

[Charles]

A huge, huge +1 to Brian's much more logical reasoning to fix this back to the old behavior.

(In reply to Brian Norris from comment #25)
> While I read and understand Thomas D.'s comments about how TAB should create
> a new 'To' box, I respectfully disagree. I believe this issue is purely a
> regression and should be fixed to retain the old behavior. AFAICT, there was
> never a conscious UI decision to change the long-standing behavior of
> Thunderbird's compose window in this case, and so it should go through a
> proper UI review if it's going to be changed.
> 
> Additionally, the current behavior is extremely inconsistent. If I type an
> address that is NOT in my autocomplete list, then TAB still works like it
> used to. I see this as yet another sign that this is a regression, not an
> intentional change.
> 
> So please, let's consider this report a regression and get it fixed as such.
> This issue has seriously annoyed me (and presumably others on this ticket),
> and I'm just happy to find that someone else cared enough to report it
> already.
> 
> Thanks!

Comment 27

[Richard Marti (:Paenglab)]

Magnus, I'm for the old behavior and you should ask for review.

ENTER has to go to the next addressing field and TAB to the subject. It makes no sense to have two different keystrokes making the same. ENTER is like a CR saying "go to next line" which is fine. TAB says "go to the next widget" and the next widget is the subject field as the addressing widget with it's multiple lines is one widget.

Comment 28

[Thomas D. (:thomas8)]

(In reply to Thomas D. from comment #16)
> At second thoughts, I'm not very convinced of the behaviour proposed in this
> bug, although I do sympathise with its purpose of streamlining the tab
> circle for this particular scenario (so I'm a bit in between, no too strong
> feelings about this so far...).

As indicated in my comment 16, so far I'm not so certain about this and no strong feelings involved, so I won't get in the way of fixing this bug unless new compelling findings suggest otherwise.
In fact, my comment 16 isn't very good; it's partly inaccurate because I mixed up two different scenarios. That's also because we don't have clear STR, and there are a lot of implicit assumptions made in this bug which should be explicit to avoid misunderstandings.

STR
1 compose new msg
2 in exactly the last empty recipient row (with set recipient type), type a searchword which triggers at least one autocomplete suggestion: e.g. [To: ][searchword >> autocomplete suggestion]
3 press <tab>

Actual Result (TB31)

a) focus moves away from the current recipient row immediately (regardless if autocompletion is finished or not, depending on typing speed and autocomplete response time, see Bug 1012397).
b) a new empty recipient row is created (this bug)
c) the just-added recipient row gets focus
It's important to note that this particular bug is exclusively about b), whether <tab> in this very narrow scenario should create a new recipient row or not.

Expected Result (as in TB24)

b) don't create a new empty recipient row (this bug)
c) As a consequence, as there's no other (empty or filled) row widget after the just-filled row widget, move focus to the next widget, which happens to be Subject box.

I think previous commenters have a good point saying for that specific scenario, <tab> should just get us to the next widget (subject box) without creating a new recipient line along the way, which if desired can be achieved with <enter>. That's efficient and arguably ux-consistent (depending on pov). So I'm sympathetic, perhaps even supportive of that idea. :)

I think both my comment 16 and comment 27 missed the distinction between two different scenarios:

Scenario 1 (regression, this bug)

Legitimate, but very narrow scenario: <tab> when autocompleting a new recipient in the last row which has recipient type set
-> move focus directly to subject field (without creating a new recipient row)

Scenario 2 (same behaviour as in TB24, no regression here)

using <tab> in any other recipient row (except those specified in scenario 1), regardless if involving autocompletion or not
-> moves focus along each and every recipient and corresponding recipient type selectors, including "empty" recipient rows IF they already have their recipient type selector set (so an existing semi-empty row like [To: ][      ] is always included in the <tab> sequence and it's not in the scope of this bug to change that.)

Comment 29

[Thomas D. (:thomas8)]

Magnus, can you reply to last paragraph of this comment?

(In reply to Richard Marti (:Paenglab) from comment #27)
> Magnus, I'm for the old behavior and you should ask for review.

That's fine with me.

> ENTER has to go to the next addressing field and TAB to the subject. It
> makes no sense to have two different keystrokes making the same. ENTER is
> like a CR saying "go to next line" which is fine. TAB says "go to the next
> widget" and the next widget is the subject field as the addressing widget
> with it's multiple lines is one widget.

Well, it'll be one widget when it will be one widget: after Bug 440377.
Current TB behaviour is different (correct/desirable or not): We have many places in UI where <tab> navigates elements below the perceived "widget level":
- message composition's header area (<tab> navigates all existing recipient and recipient type fields)
- message reader's header area (<tab> navigates all recipients and worse, two stops for each recipient as each star has its own useless stop; existing bug)
- message reader's body area (<tab> navigates all links found in body)

So the <tab> behaviour wrt this bug really depends on scenario, as explained in my comment 28.

@Magnus:
OT: That said, I like Richard's idea to think of the recipient area as a single widget with multiple lines, where <enter> creates a new line (similar to word processors).
In the same line of thought, what happened to <cursor up/down> keys in recipient area (when not autocompleting)? I recall they used to work in previous versions of TB, so that's looks like another regression, right? In TB31, it's now very hard and cumbersome to move around in the list of existing recipients using keyboard only, only <tab> and <shift+tab> are possible... Magnus, can you comment?

Comment 30

[Hungerburg]

Speaking as someone, who has gotten used to hitting TAB twice, still thinking, that some consistency might be desirable, so below a try to find a semantic for the different key capabilities:

# TAB navigates the form as presented initially
# ENTER creates new fields (composer) or submits the form (web)

Of course all of the world is inconistent, yet day by day humans manage somehow and hitting one more key to compose an email message will not grind the economy to a halt ;) But at least a key should not have different meanings in a single widget, i.e. depending on whether auto-complete found the time and occasion to fire…

Comment 31

[Magnus Melin [:mkmelin]]

Comment on attachment 8463013 [details] [diff] [review]
bug1043784_tab_adds_address_row.patch

Yeah, I think I'm convinced we should do this.
(This patch does not fix bug 1051564)

Comment 32

[Charles]

(In reply to Magnus Melin from comment #31)
> Comment on attachment 8463013 [details] [diff] [review]
> bug1043784_tab_adds_address_row.patch
> 
> Yeah, I think I'm convinced we should do this.

What does 'do this' mean?

Revert the behavior to what it has been for the last 10 years (hopefully)?

Thanks for working on it!

Comment 33

[Richard Marti (:Paenglab)]

(In reply to Charles from comment #32)
> 
> What does 'do this' mean?

Old behavior.

Comment 34

[Richard Marti (:Paenglab)]

Comment on attachment 8463013 [details] [diff] [review]
bug1043784_tab_adds_address_row.patch

Review of attachment 8463013 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.

I must doing something wrong, but it fixes bug 1051564 for me.

Comment 35

[Magnus Melin [:mkmelin]]

It only fixes it partly, that is, when there's no match yet. Once you complete to a value you can't shift-tab back to the address type widget.

Comment 36

[Charles]

(In reply to Richard Marti (:Paenglab) from comment #33)
> (In reply to Charles from comment #32)
>> 
>> What does 'do this' mean?

> Old behavior.

Excellent, thanks...

Sadly, this didn't make it into 31.1...

Comment 37

[Marco Zehe (:MarcoZ)]

I am also all for fixing this bug sooner rather than later. It bits me every day and annoys me at least 20 times per day when it does. I am a long-time Thunderbird user, and this change really freaks me out. Sorry for being so blunt!

Comment 40

[Mike Conley (:mconley) (:⚙️)]

Comment on attachment 8463013 [details] [diff] [review]
bug1043784_tab_adds_address_row.patch

Review of attachment 8463013 [details] [diff] [review]:
-----------------------------------------------------------------

Patch looks good - thanks Magnus.

Comment 41

[Magnus Melin [:mkmelin]]

https://hg.mozilla.org/comm-central/rev/57ec66cb59ab -> FIXED

Comment 42

[Magnus Melin [:mkmelin]]

Comment on attachment 8463013 [details] [diff] [review]
bug1043784_tab_adds_address_row.patch

[Approval Request Comment]
Regression caused by (bug #): bug 959209
User impact if declined: tab in autocomplete adds a new line, instead of just going to end of completion
Testing completed (on c-c, etc.): landed on trunk
Risk to taking this patch (and alternatives if risky): not risky

Comment 43

[Mark Banner (:standard8)]

Comment on attachment 8463013 [details] [diff] [review]
bug1043784_tab_adds_address_row.patch

[Triage Comment]
Should land on aurora & beta first.

Comment 44

[Mark Banner (:standard8)]

https://hg.mozilla.org/releases/comm-aurora/rev/a22b167c6957
https://hg.mozilla.org/releases/comm-beta/rev/0c70f8c7a864

Comment 45

[Charles]

Any chance this can be backported to TB 32, so we don't have to wait forever for the fix... :)

Comment 46

[Wayne Mery (:wsmwk)]

(In reply to Charles from comment #45)
> Any chance this can be backported to TB 32, so we don't have to wait forever
> for the fix... :)

Hopefully you mean TB 31.  And the intentions are extremely clear if you reexamine the flags and comments.

Comment 47

[Charles]

Yes, I meant 31, sorry, but...

Flags say 'None yet set'... am I missing something?

And I don't see any specific comment that actually says this will land in 31.x...

But if it will, then fine... thanks...

Comment 48

[Wayne Mery (:wsmwk)]

You must have missed comment 42 "Flags: approval-comm-esr31?", is the standard way to request landing on the release.

Comment 49

[Charles]

Oops, yeah, sorry about that...

But shouldn't that be reflected in the 'Flags' for the bug?

Although I do see it now also in the 'Attachments' section...

Oh well, I'll look more carefully next time...

Thanks again!

Comment 51

[Mark Banner (:standard8)]

https://hg.mozilla.org/releases/comm-esr31/rev/ba2e66184ee5

Comment 52

[Magnus Melin [:mkmelin]]

We should probably back this out for ESR, since it makes bug 1107844 so much more exposed.

Comment 53

[Mark Banner (:standard8)]

Ok, thanks Magnus, I've just backed it out:  https://hg.mozilla.org/releases/comm-esr31/rev/3b6a364c4650

Comment 54

[Jorg K (CEST = GMT+2)]

Since the fix to bug 1043310 (and therefore bug 1107844) has landed for ESR31, this fix should probably be put back in for ESR31, right, Magnus?

Comment 55

[Mark Banner (:standard8)]

Magnus has the most context there.

Comment 56

[Magnus Melin [:mkmelin]]

It should be safe to re-land it now yes.

Comment 57

[Jorg K (CEST = GMT+2)]

Please land for ESR31.
One question: Landing this on 35 (comment #43 and comment #44) means that we will see it in beta 36 one day soon now?

Comment 58

[Kent James (:rkent)]

Magnus, my understanding is that you and I now have approval+ privileges in BMO. So you can make the call on approval-comm-esr31

Comment 59

[Magnus Melin [:mkmelin]]

Jorg: this already has status-thunderbird34:fixed and status-thunderbird35:fixed, and target milestone 36. It's long since this landed.

Comment 60

[Magnus Melin [:mkmelin]]

https://hg.mozilla.org/releases/comm-esr31/rev/fbb5a78e7140