Labels in Rackspace email are not displaying correctly

RESOLVED INVALID

Status

()

Core
JavaScript Engine
RESOLVED INVALID
2 years ago
2 years ago

People

(Reporter: jrh, Unassigned)

Tracking

({regression, site-compat})

46 Branch
regression, site-compat
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
Created attachment 8714846 [details]
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

2 years ago
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)
(Reporter)

Comment 2

2 years ago
Created attachment 8714882 [details]
unreachable-code-after-return-statement.js
Flags: needinfo?(jhoward)
(Reporter)

Comment 3

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

Comment 4

2 years ago
(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)
(Reporter)

Comment 5

2 years ago
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)

Comment 6

2 years ago
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)

Updated

2 years ago
Keywords: regression, site-compat

Comment 7

2 years ago
(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)

Updated

2 years ago
Component: Untriaged → JavaScript Engine
Product: Firefox → Core

Comment 8

2 years ago
Clearing NI for Josh since he gave me test credentials to use with the app.
Flags: needinfo?(jhoward)

Comment 9

2 years ago
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

2 years ago
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.
(Reporter)

Comment 12

2 years ago
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.
(Reporter)

Comment 14

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

Comment 15

2 years ago
Hurray. Closing per comment 14.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.