Manual setup error message when IMAP and SMTP settings are wrong returns "{{server}}" string instead of the actual server

VERIFIED FIXED in Firefox OS v2.1

Status

Firefox OS
Gaia::E-Mail
VERIFIED FIXED
3 years ago
2 years ago

People

(Reporter: Nefzaoui, Assigned: mcav)

Tracking

({regression})

unspecified
2.1 S5 (26sep)
x86
Linux
regression

Firefox Tracking Flags

(blocking-b2g:2.1+, b2g-v2.0 unaffected, b2g-v2.1 verified, b2g-v2.2 verified)

Details

Attachments

(3 attachments)

(Reporter)

Description

3 years ago
Created attachment 8484966 [details]
Bug Screenshot 2014-09-05-14-54-51

Manual email configuration error message returns "{{server}}" string instead of the actual server when IMAP and SMTP addresses are not reachable.
(Reporter)

Comment 1

3 years ago
Théo,
You might wanna look at this?

Thanks!
Flags: needinfo?(tchevalier)
D'oh, good catch Ahmed, I can reproduce.

I'll take a look at the code.
Flags: needinfo?(tchevalier)
This regression isn't a direct l10n problem.  It's fallout from backend changes in bug 885110.  The incoming (IMAP and POP3) configurator no longer returns an errorDetails structure on failure cases.  That structure would previously have contained a 'server' parameter that would have been interpolated into the string.

We need to make sure that we are returning the dictionary for the following strings:
- bad-security
- unresponsive-server
- server-problem
- server-maintenance

I think we may just end up addressing this for bug 1059100 since it's aggressively targeted for v2.1 uplift and we're touching autoconfig code-paths there already.  (Noting that the unit tests we care about are the prober tests.)
status-b2g-v2.0: --- → unaffected
status-b2g-v2.1: --- → affected
status-b2g-v2.2: --- → affected
Depends on: 885110

Updated

3 years ago
Keywords: regression
Theo - Would this be a blocker for l10n in 2.1, since this results in portion of the string to be untranslated? If so, should we nominate this to block?
Flags: needinfo?(tchevalier)
I'd say yes:

[Blocking Requested - why for this release]:

Looks like we have at least 4 strings (that's what I understand from #c3 ) with a broken variable. Information provided by the variable is missing to the user, and overall product quality looks bad. AFAICT, we never shipped with broken variables for all locales, I'd love to see this keep going :)
And especially with 2.1 where we'll have users with more high-end expectations (I believe this needs to be taken into account as well).
blocking-b2g: --- → 2.1?
Flags: needinfo?(tchevalier)
triage: 2.1+ for regression and reasons in comment 5.

Marcus, if this fix is included in bug 1059100 can you add that to the dependencies?
blocking-b2g: 2.1? → 2.1+
Flags: needinfo?(m)
I don't think this is going to happen as part of bug 1059100, so this should just happen on its own; I thought we were going to touch that code-path, but we didn't and this does merit its own improved test coverage.

Updated

3 years ago
Keywords: regressionwindow-wanted

Updated

3 years ago
Keywords: regressionwindow-wanted
(Assignee)

Updated

3 years ago
Assignee: nobody → m
Status: NEW → ASSIGNED
Flags: needinfo?(m)
Target Milestone: --- → 2.1 S4 (12sep)
(Assignee)

Comment 8

3 years ago
Created attachment 8487359 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files
Attachment #8487359 - Flags: review?(bugmail)
Comment on attachment 8487359 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files

r=asuth.  Restating my understanding: there is a single point of reporting for IMAP/POP3 via the composite configurator.  In the all().catch() case we do a clever thing (which I failed to fully appreciate before!) where we then figure out which promise got rejected by process of elimination with a bias towards reporting the IMAP server as the jerk in the event both got rejected.  The tests lacked fidelity here; we now specify fake server names and ensure that the values are propagated, also reporting more.  We should now be unable to regress for IMAP/POP3.

ActiveSync is not affected, even with my recent changes to autoconfig probing, because we are still using the (newly factored out for oauth2 support) _createAccountUsingFullInfo.  That method always populates failureDetails with the server and it always reports those details.

So we are now golden.  Thanks, mcav!  And thanks :Nefzaoui and :tchevalier for being so on-top of this!
Attachment #8487359 - Flags: review?(bugmail) → review+
(Assignee)

Comment 10

3 years ago
gaia master: https://github.com/mozilla-b2g/gaia/commit/d4cf33394528eee14a8329c483f2df8d6dc5c1b6
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
(Assignee)

Updated

3 years ago
status-b2g-v2.2: affected → fixed
(Assignee)

Comment 11

3 years ago
Comment on attachment 8487359 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files

Requesting approval for v2.1: without this patch, the user will see "{{server}}" rather than the actual server name.

[Approval Request Comment]
[Bug caused by] (feature/regressing bug #): bug 885110
[User impact] if declined:
[Testing completed]: yes
[Risk to taking this patch] (and alternatives if risky): low
[String changes made]:
Attachment #8487359 - Flags: approval-gaia-v2.1?
This is not fixed on my flame with build 20140916160204
(In reply to Tim Maks van den Broek [:mad_maks] from comment #12)
> This is not fixed on my flame with build 20140916160204

Can QA verify?
Keywords: qawanted
Comment on attachment 8487359 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files

Switching to qa-approval to verify before uplift.

Josh - Can you have someone test this to see if this works or not?
Attachment #8487359 - Flags: approval-gaia-v2.1? → qa-approval?(jmitchell)

Updated

3 years ago
Keywords: qawanted
Comment on attachment 8487359 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files

Opps didn't mean to remove the approval flag here.
Attachment #8487359 - Flags: approval-gaia-v2.1?
QA Contact: jmitchell
(In reply to Jason Smith [:jsmith] from comment #14)
> Comment on attachment 8487359 [details] [review]
> Link to Github pull-request:
> https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files
> 
> Switching to qa-approval to verify before uplift.
> 
> Josh - Can you have someone test this to see if this works or not?

So far I have not been able to apply this patch - Approaching round-table and then EOD so I'll try and revisit this tomorrow.

I'm getting hung-up on step 3 of our document / process
example: 3. git checkout Bug1009223 (<- this needs to match exactly the dev’s patch name provided on the Github website)
(In reply to Joshua Mitchell [:Joshua_M] from comment #16)
> (In reply to Jason Smith [:jsmith] from comment #14)
> > Comment on attachment 8487359 [details] [review]
> > Link to Github pull-request:
> > https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files
> > 
> > Switching to qa-approval to verify before uplift.
> > 
> > Josh - Can you have someone test this to see if this works or not?
> 
> So far I have not been able to apply this patch - Approaching round-table
> and then EOD so I'll try and revisit this tomorrow.
> 
> I'm getting hung-up on step 3 of our document / process
> example: 3. git checkout Bug1009223 (<- this needs to match exactly the
> dev’s patch name provided on the Github website)

Josh - Let's focus on verifying this on trunk instead of applying the patch. Can you do that?
I've verified the bug is not fixed on trunk, at least per nightly builds.  It's not making it all the way through to the front-end still.  I understand :mcav is busy so I'll further augment the back-end tests and verify the fix on device.  We can also hold back on the v2.1 uplift and/or v2.2 landing if Fabrice would prefer we wait for front-end integration tests for this; given our bad here, that does sound reasonable to me.  That should be happening during this sprint.

full debug trace is:
09-17 19:40:50.689 I/Gecko   ( 1866): MailBridge(undefined)["cmd","tryToCreateAccount",26212134.053000003,30,26212478.167,31,null]
09-17 19:40:51.039 I/Gecko   ( 1866): WINF: [slog] probe:imap:connecting {"connInfo":{"hostname":"cghhfg.bhhg","port":"993","crypto":"ssl"}}
09-17 19:40:51.039 I/Gecko   ( 1866): WLOG: [slog] oauth:credentials-ok
09-17 19:40:51.039 I/Gecko   ( 1866): WINF: [slog] probe:smtp:connecting {"_credentials":{"username":"dfhg@fgggcf","password":"cghhcc","outgoingUsername":"dfhg@fgggcf","outgoingPassword":"cghhcc"},"connInfo":{"emailAddress":"dfhg@fgggcf","hostname":"dfjdf.fgch","port":"465","crypto":"ssl"}}
09-17 19:40:51.039 I/Gecko   ( 1866): WLOG: [slog] oauth:credentials-ok
09-17 19:40:51.049 I/Gecko   ( 1866): WLOG: [slog] smtp:connect {"_auth":{"user":"dfhg@fgggcf","pass":"cghhcc","xoauth2":null},"usingOauth2":false,"connInfo":{"emailAddress":"dfhg@fgggcf","hostname":"dfjdf.fgch","port":"465","crypto":"ssl"}}
09-17 19:40:51.399 I/Gecko   ( 1866): WERR: [slog] imap:normalized-error {"error":{"name":"ConnectionRefusedError","message":""},"errorName":"ConnectionRefusedError","errorMessage":"","socketLevelError":"unresponsive-server","protocolLevelError":null,"reportAs":"unresponsive-server"}
09-17 19:40:51.409 I/Gecko   ( 1866): WERR: [slog] imap:connect-error {"error":"unresponsive-server","connInfo":{"hostname":"cghhfg.bhhg","port":"993","crypto":"ssl"}}
09-17 19:40:51.409 I/Gecko   ( 1866): WERR: [slog] imap:normalized-error {"error":"unresponsive-server","socketLevelError":"unresponsive-server","reportAs":"unresponsive-server"}
09-17 19:40:51.409 I/Gecko   ( 1866): WERR: [slog] probe:imap:error {"error":"unresponsive-server"}
09-17 19:40:51.409 I/Gecko   ( 1866): WLOG: [slog] smtp:analyzed-error {"rawError":{"name":"ConnectionRefusedError","message":""},"rawErrorName":"ConnectionRefusedError","rawErrorMessage":"","normalizedError":"unresponsive-server","errorName":"ConnectionRefusedError","errorMessage":"","wasSending":false}
09-17 19:40:51.419 I/Gecko   ( 1866): WERR: [slog] smtp:connect-error {"error":"unresponsive-server","connInfo":{"emailAddress":"dfhg@fgggcf","hostname":"dfjdf.fgch","port":"465","crypto":"ssl"}}
09-17 19:40:51.419 I/Gecko   ( 1866): WLOG: [slog] smtp:analyzed-error {"rawError":"unresponsive-server","normalizedError":"unresponsive-server","wasSending":false}
09-17 19:40:51.419 I/Gecko   ( 1866): WERR: [slog] probe:smtp:error {"error":"unresponsive-server","connInfo":{"emailAddress":"dfhg@fgggcf","hostname":"dfjdf.fgch","port":"465","crypto":"ssl"}}
09-17 19:40:51.419 I/Gecko   ( 1866): MailBridge(undefined)["send","tryToCreateAccountResults",26938408.167999998,32,{"type":"tryToCreateAccountResults","handle":6,"account":null,"error":"unresponsive-server"}]
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #8487359 - Flags: qa-approval?(jmitchell)
Attachment #8487359 - Flags: approval-gaia-v2.1?

Updated

3 years ago
status-b2g-v2.2: fixed → affected
Er, or perhaps we are fine on trunk and it's just our nightly update process can be misleading when it reports "last updated" independent of the build timestamp because it used a build it found out about days ago but only just installed.

(In reply to Tim Maks van den Broek [:mad_maks] from comment #12)
> This is not fixed on my flame with build 20140916160204

This build does not include mcav's fix.

This build uses hg commit:
http://hg.mozilla.org/integration/gaia-central/rev/123eb4378d299e61d73be5e290f7d9ca00f2fb41
Mon Sep 15 13:39:43 2014 -0400 (at Mon Sep 15 13:39:43 2014 -0400)

mcav's fix is literally 2 commits after that commit at hg commit:
http://hg.mozilla.org/integration/gaia-central/rev/dfd43422f8a8
Mon Sep 15 13:58:09 2014 -0700 (at Mon Sep 15 13:58:09 2014 -0700)

I'm going to manually re-verify now, but in fact things look okay when accounting for that and after re-inspecting the unit tests.
status-b2g-v2.2: affected → fixed
I am NOT able to repro this bug in the latest Master (KK base) - 

Actual Results - the name of the server appears instead of {{server}}


Device: Flame 2.2 Master
BuildID: 20140917114258
Gaia: 72262d054ffa5d0d2b5a0033f713149281511aea
Gecko: d2c01d77b9d0
Version: 35.0a1 (2.2 Master)
Firmware: 165
User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
Yeah, it's fine on trunk when using a trunk build that includes the gaia fix.  Re-requesting uplift and re-certifying that our backend tests do test the end-to-end tryToCreateResults and this is reflected in our logs:

09-17 20:00:19.519 I/Gecko   ( 2681): MailBridge(undefined)["send","tryToCreateAccountResults",179903536.779,113,{"type":"tryToCreateAccountResults","handle":7,"account":null,"error":"unresponsive-server","errorDetails":{"server":"xggxdfhhv.vvh"}}]


Also, I'm just going back to only using flash-b2g and pretending OTA updates don't exist since my 2.2 build is still insisting it doesn't have any new updates for me.
Status: REOPENED → RESOLVED
Last Resolved: 3 years ago3 years ago
Resolution: --- → FIXED
Comment on attachment 8487359 [details] [review]
Link to Github pull-request: https://github.com/mozilla-b2g/gaia-email-libs-and-more/pull/337/files

See prior request.
Attachment #8487359 - Flags: approval-gaia-v2.1?(fabrice)

Updated

3 years ago
Status: RESOLVED → VERIFIED
Attachment #8487359 - Flags: approval-gaia-v2.1?(fabrice) → approval-gaia-v2.1+
(Assignee)

Comment 23

3 years ago
whew!
v2.1: https://github.com/mozilla-b2g/gaia/commit/b0b0ab8e0de5d1150feaf76f63f437edf695f15f
status-b2g-v2.1: affected → fixed
Target Milestone: 2.1 S4 (12sep) → 2.1 S5 (26sep)
(In reply to Tim Maks van den Broek [:mad_maks] from comment #12)
> This is not fixed on my flame with build 20140916160204

I can confirm it is fixed for build 20140918040210 in my Flame
[Environment]
Gaia-Rev        3742913e11f69e789dcb0aa0dedf2e5572da0129
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-aurora/rev/df42b05782aa
Build ID        20140922185144
Version         34.0a2
Device Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20140922.221301
FW-Date         Mon Sep 22 22:13:10 EDT 2014
Bootloader      L1TC10011800

[Result]
PASS
QA Whiteboard: [COM=Gaia::E-Mail]
status-b2g-v2.1: fixed → verified
Created attachment 8527513 [details]
verified_v2.1.jpg

Add verified attachments:"verified_v2.1.jpg".
This bug has been verified successfully on Flame v2.1

Flame 2.1 build:
Gaia-Rev        afdfa629be209dd53a1b7b6d6c95eab7077ffcd9
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g34_v2_1/rev/dc3018cbdbe6
Build-ID        20141123001201
Version         34.0
This bug has been verified successfully on Flame v2.2.
See verified_v2.1.jpg.
Reproducing rate:0/5.

FLame 2.2 build:
Gaia-Rev        824a61cccec4c69be9a86ad5cb629a1f61fa142f
Gecko-Rev       https://hg.mozilla.org/mozilla-central/rev/acde07cb4e4d
Build-ID        20141125040209
Version         36.0a1
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20141125.113029
FW-Date         Tue Nov 25 11:30:43 EST 2014
Bootloader      L1TC00011880
status-b2g-v2.2: fixed → verified
You need to log in before you can comment on or make changes to this bug.