Closed Bug 1245126 Opened 5 years ago Closed 4 years ago

Labels in Rackspace email are not displaying correctly

Categories

(Core :: JavaScript Engine, defect)

46 Branch
defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: jrh, Unassigned)

References

Details

(Keywords: regression, site-compat)

Attachments

(2 files)

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.
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 ) ?
Component: General → Untriaged
Flags: needinfo?(jhoward)
Flags: needinfo?(jhoward)
New profile is able to reproduce. No errors, but the two warnings included in those pretty large JS dumps.
(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.
Flags: needinfo?(jhoward)
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
Flags: needinfo?(jhoward)
Shu, this looks like a regression from block-level functions. Anything we can do beyond lumping it over to tech evangelism?
Blocks: 1071646
Flags: needinfo?(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?
Flags: needinfo?(shu) → needinfo?(jhoward)
Component: Untriaged → JavaScript Engine
Product: Firefox → Core
Clearing NI for Josh since he gave me test credentials to use with the app.
Flags: needinfo?(jhoward)
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");
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.
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.
Should anyone from Rackspace look at this bug, it is related to an open Rackspace issue: Support #1914007
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.
It appears Rackspace fixed the issue (somewhere between their 12.0 and 12.1.1-RC of their webapp.)
Hurray. Closing per comment 14.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.