1245126 - Labels in Rackspace email are not displaying correctly

Status: RESOLVED INVALID

(Core :: JavaScript Engine, defect)

Description

[Josh Howard [:jrh]]

Attachment: Rackspace Email Screenshot.png

The rendering of certain labels in Rackspace's webmail app don't work correctly in Firefox 46 (currently running 46.0a2 (2016-02-02)), but do in other version (such as 45.) Unfortunately this application isn't readily available for viewing unless you have a Rackspace account, but I can provide whatever info is needed.
I've attached a composite image with Firefox 46 and an Firefox 45, just to compare.

Comment 1

[:Gijs (he/him)]

Are there any errors in the web console (ctrl-shift-k on windows/linux, cmd-opt-k on osx) when this happens? Can you reproduce this if you try on a clean profile ( https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles ) ?

Comment 2

[Josh Howard [:jrh]]

Attachment: unreachable-code-after-return-statement.js

Comment 3

[Josh Howard [:jrh]]

New profile is able to reproduce. No errors, but the two warnings included in those pretty large JS dumps.

Comment 4

[:Gijs (he/him)]

(In reply to Josh Howard [:jrh] from comment #3)
> New profile is able to reproduce. No errors, but the two warnings included
> in those pretty large JS dumps.

Thanks. Also, hrmpf. The lack of errors is unhelpful. :-(

Can you try to run mozregression to figure out when this broke? ( https://mozilla.github.io/mozregression/ )

mozregression --good 45 --bad 46

should produce usable output. If you can keep a login state for this across restarts it might be easier for you if you create a profile specifically to test with, login there, and pass the path to that profile with --profile.

Comment 5

[Josh Howard [:jrh]]

Not sure if any of the context is helpful, but it seems like mozregression did identify a specific bug:

 9:11.59 LOG: MainThread Test Runner INFO Running mozilla-inbound build built on 2015-12-09 16:00:53.416000, revision d5512906
 9:34.24 LOG: MainThread Test Runner INFO Launching /private/var/folders/jq/g0h5yt555ps0sf2xf8fzlrgr0000gn/T/tmp_E7hev/Nightly.app/Contents/MacOS/firefox
 9:34.24 LOG: MainThread mozversion INFO application_buildid: 20151209071542
 9:34.24 LOG: MainThread mozversion INFO application_changeset: d55129069a1f56f63573282911ad2dac17d6e7b1
 9:34.24 LOG: MainThread mozversion INFO application_name: Firefox
 9:34.24 LOG: MainThread mozversion INFO application_repository: https://hg.mozilla.org/integration/mozilla-inbound
 9:34.24 LOG: MainThread mozversion INFO application_version: 45.0a1
Was this inbound build good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', 'back' or 'exit' and press Enter): good
 9:42.43 LOG: MainThread Bisector INFO Narrowed inbound regression window from [df984239, ffd21df8] (3 revisions) to [d5512906, ffd21df8] (2 revisions) (~1 steps left)
 9:42.43 LOG: MainThread main INFO Oh noes, no (more) inbound revisions :(
 9:42.43 LOG: MainThread Bisector INFO Last good revision: d55129069a1f56f63573282911ad2dac17d6e7b1
 9:42.43 LOG: MainThread Bisector INFO First bad revision: ffd21df83fee3ee19c894df4f3b55e58c9f25e58
 9:42.43 LOG: MainThread Bisector INFO Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d55129069a1f56f63573282911ad2dac17d6e7b1&tochange=ffd21df83fee3ee19c894df4f3b55e58c9f25e58

 9:43.04 LOG: MainThread main INFO Looks like the following bug has the changes which introduced the regression:
https://bugzilla.mozilla.org/show_bug.cgi?id=1071646

Comment 6

[:Gijs (he/him)]

Shu, this looks like a regression from block-level functions. Anything we can do beyond lumping it over to tech evangelism?

Comment 7

[Shu-yu Guo [:shu]]

(In reply to :Gijs Kruitbosch from comment #6)
> Shu, this looks like a regression from block-level functions. Anything we
> can do beyond lumping it over to tech evangelism?

I need to figure out the offending code on Rackspace to say if there's anything we can do.

Josh, what are the STR for this if I don't have a Rackspace account? Could you provide a dump of all JS files on their email webapp? Or is there perhaps a test account I could use?

Comment 8

[Shu-yu Guo [:shu]]

Clearing NI for Josh since he gave me test credentials to use with the app.

Comment 9

[Shu-yu Guo [:shu]]

I managed to come up with a minimal failing test case that causes this bug. Investigating why.

if (1) {
  if (1) {
    if (!this.L) {
      L = function () { return "bad"; }
    }
  }
  function L() { return "good"; }
}
assertEq(L(), "good");

Comment 10

[Shu-yu Guo [:shu]]

What's going on above is that the |L = function() { return "bad"; }| assignment is assigning to the block-local L. Come time for the annex B assignment at the text location of |function L() { return "good"; }|, the value of the block-local L is actually the "bad" function, since function statements are hoisted to the top of their block.

I think this is a spec bug in step 1.a.ii.3.e in B.3.3.1 and analogous locations in B.3.3.2 and B.3.3.3. 

Our implementation is to spec, I believe, but the spec is very surprising for this corner case. The intuitive thing would be for the "good" function to be assigned in the Annex B semantics.

Will follow up with TC39.

Comment 11

[Mike Taylor [:miketaylr]]

I've been in contact with some Rackspace Webmail engineers who will be looking at this soon and will ask any questions they have here in the bug.

Comment 12

[Josh Howard [:jrh]]

Should anyone from Rackspace look at this bug, it is related to an open Rackspace issue: Support #1914007

Comment 13

[Mike Taylor [:miketaylr]]

I received a reply from a Rackspace Webmail engineer: "We are in the midst of a logjam in our release pipeline but we have a fix for this queued up. I don’t know when FF 46 will be released but I hope we’ll have this fix out there before it happens."

Thanks to Rackspace for the responsiveness, much appreciated.

Comment 14

[Josh Howard [:jrh]]

It appears Rackspace fixed the issue (somewhere between their 12.0 and 12.1.1-RC of their webapp.)

Comment 15

[Shu-yu Guo [:shu]]

Hurray. Closing per comment 14.