Closed Bug 1012944 Opened 9 years ago Closed 9 years ago

User login and account creation on broken since Firefox 30.0b1, say home.display is not a function


(Core :: DOM: Core & HTML, defect)

Not set



Tracking Status
firefox29 --- unaffected
firefox30 --- unaffected
firefox31 + verified
firefox32 + verified


(Reporter: whimboo, Assigned: bzbarsky)




(4 keywords)


(2 files)

Yesterday I have noticed with my Aurora build that I cannot log into anymore. I had to do that, given that I accidentally removed my cookies in the given Firefox profile. I quickly checked which versions of Firefox are affected, and it goes back to 30.0b1. Firefox 29.0.1 is not affected.

1. Go to
2. Login if you already have an account, or create a new account
3. Submit your entered data 

After step 3 you will be redirected to the start page. There is no way to create an account or to login.

I will do a regression test tomorrow, if no-one else got already around it.
The console says TypeError: home.display is not a function

if (typeof (home) == 'undefined') {
  var home = {
    display: function (abtest) {

So I guess this is the same issue as Bug 989584.
Assignee: nobody → english-other
Component: General → English Other
Depends on: 976920
Product: Firefox → Tech Evangelism
Summary: User login and account creation on broken since Firefox 30.0b1 → User login and account creation on broken since Firefox 30.0b1, say home.display is not a function
Version: 31 Branch → unspecified
Specifically this causes the error:

$(document).ready(function() {
Attached file testcase
Hrm.  If other browsers don't support window.home(), can we just remove it?  I doubt anyone would seriously use this anyway; I see no uses in our tree or in addons.
Flags: needinfo?(peterv)
Neither IE11 nor Chrome has this function.
Thanks Kohei for checking that. It clearly saves me the time for a regression test.
Sure, let's kill window.home()
(In reply to Boris Zbarsky [:bz] from comment #4)
> Hrm.  If other browsers don't support window.home(), can we just remove it? 
> I doubt anyone would seriously use this anyway; I see no uses in our tree or
> in addons.

Actually, I see a little usage in e.g. and . (which is completely orthogonally interesting because these differently branded add-ons seem to share a lot of code...) . I'd still argue we should probably just remove this though.
Keywords: addon-compat
Yeah, looks like addons mxr was lying to me.  I see some uses in there.

I'll just make this chromeonly.  Peter was OK with nuking this from the web.  I'll probably do the same with back() and forward() while I'm here.
Assignee: english-other → nobody
Component: English Other → DOM
Flags: needinfo?(peterv)
Product: Tech Evangelism → Core
Assignee: nobody → bzbarsky
For Firefox 30 we'll handle this via bug 976920.

For Firefox 31 and later I'd like to backport this patch.

Also, the code cited in comment 1 doesn't do (luckily) what its author thinks it does...
Whiteboard: [need review]
I have a friend working at Deezer. Let me know if I can help.
We don't need them to do anything, thanks!
Attachment #8425551 - Flags: review?(peterv) → review+
Boris: for the record: I'm more worried about nuking back() and forward() than home(). Please consider removing home() only. 

Just gut feeling, but I think there is significant usage of back(), much less usage of forward() but likely some. If we have some telemetry / usage measurements you could enable for these methods it might tell us more about their "removability"..
I was thinking the same thing, but seems like window.back() and window.forward() are Gecko-specific obscure methods. People are using the standard history.back() and history.forward() methods implemented in all browsers. It might be safe to remove these.
Keywords: dev-doc-needed
Right.  history.back()/forward() are used a lot.  I would expect that window.back()/forward() are not.

I did consider removing only home(), but I would expect that the compat worries from name collisions on back/forward are bigger than the ones from the removal...

I could add telemetry (though we don't have a sane system for doing it for this sort of thing), but I'm not sure we need it in this case. - unfortunately I haven't found a way to use a real literal string (or regexp) search on github..
Hmm.... says only Presto and Gecko support this.

I'm willing to take the chance on those functions.
I can see some on GitHub but most of them are probably Firefox extensions or Firefox OS apps. [ChromeOnly] won't affect extensions, and the latter case is subject to tech evang. We can't help legacy, unmaintained "Best viewed with Netscape" sites but those might have already been broken for other reasons.
Flags: in-testsuite?
Whiteboard: [need review]
Comment on attachment 8425551 [details] [diff] [review]
Hide window.home/back/forward from web pages, since those are non-standard and cause pages to not set up their own thins with the same names

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Bug 932322 
User impact if declined: Some sites will not work correctly, unless we backport
   bug 976920 to Gecko 31.
Testing completed (on m-c, etc.): Passes tests
Risk to taking this patch (and alternatives if risky): Risk is medium to low.
    The only other UA that implemented these functions was Presto, and there are
    equivalents for back/forward on window.history that work for all objects. 
    Extensions should continue to work OK.
String or IDL/UUID changes made by this patch: None.
Attachment #8425551 - Flags: approval-mozilla-aurora?
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Attachment #8425551 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Bug 932322 is disabled on 30 so is this really affected there?
Flags: needinfo?(bzbarsky)
It's not now (but was when the bug was filed).
Flags: needinfo?(bzbarsky)
Works great with Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Firefox/32.0 ID:20140522030204 CSet: b40296602083

Thanks for the quick fix!
Same with Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 ID:20140522004003 CSet: 5239876497e2
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.