Closed
Bug 1496754
Opened 6 years ago
Closed 6 years ago
Can't create new AWS Lambda function
Categories
(Core :: DOM: Core & HTML, defect, P1)
Core
DOM: Core & HTML
Tracking
()
RESOLVED
FIXED
mozilla64
Tracking | Status | |
---|---|---|
firefox-esr60 | --- | unaffected |
firefox62 | --- | unaffected |
firefox63 | --- | unaffected |
firefox64 | + | fixed |
People
(Reporter: jdm, Assigned: twisniewski)
References
Details
(Keywords: regression, site-compat)
Steps to reproduce:
1. go to the AWS Lambda console
2. press "create function"
3. give it a name, and choose any role
4. press the "Create function"
Expected:
The function is created and the page navigations to the function configuration.
Actual:
The button stays greyed out for a while, then eventually returns to its original state and no navigation occurs. The function is not created.
mozregression points at bug 1454325 as the cause of the regression.
[Tracking Requested - why for this release]: This significantly impacts the ability to use a feature of AWS in Firefox.
Assignee | ||
Comment 1•6 years ago
|
||
Anne, what do you think? I get the feeling that between this and the Mapbox issue in bug 1494443, we need to at least make the pref added in bug 1454325 nightly-only for now (if even nightly-only), while we work the details out with site owners and other browser vendors.
Flags: needinfo?(annevk)
What's the specific problem here? Does AWS want to see a space between the semicolon and the following parameter? Is there a rationale better than minification for the serialization algorithm in the spec not putting a space there?
Updated•6 years ago
|
Comment 3•6 years ago
|
||
Yeah, it'd be good to know the specific problem here. I basically see two solutions:
1. We start serializing with a space.
2. We only modify the existing Content-Type header if the charset parameter value is not a case-insensitive (or case-sensitive as other browsers do modify otherwise, but they also modify in place and not parse-then-serialize) match for UTF-8.
I filed https://github.com/whatwg/mimesniff/issues/84 to coordinate with other implementers who are also in the process of tackling this.
Flags: needinfo?(annevk)
Updated•6 years ago
|
Priority: -- → P1
Assignee | ||
Comment 4•6 years ago
|
||
Do we have any test account credentials that I could use to sign into AWS? (And if we do, will there be a two-factor ping requiring some coordination?)
Comment 5•6 years ago
|
||
Just to update, we're asking our friends at Amazon about creds.
Comment 6•6 years ago
|
||
(In reply to Thomas Wisniewski [:twisniewski] from comment #4)
> Do we have any test account credentials that I could use to sign into AWS?
> (And if we do, will there be a two-factor ping requiring some coordination?)
You could sign up for a free account, I think: https://aws.amazon.com/free/
Assignee | ||
Comment 8•6 years ago
|
||
I'm waiting on a test-account in bug 1498268, but if that drags on too much longer I'll just bite the bullet and provide AWS with my phone number to make a free account.
Assignee | ||
Comment 9•6 years ago
|
||
(That said, we're also reverting the change that causes this in bug 1499136, so the need for this is diminished).
Assignee | ||
Comment 10•6 years ago
|
||
Anne, I finally got my test-account to confirm what's happening here. The problem here is the case-normalization, not a missing space. We're sending this:
>application/json;charset=UTF-8
But if I disable dom.xhr.standard_content_type_normalization in about:config, we send this, and the AWS Lambda function is successfully created:
>application/json;charset=utf-8
Flags: needinfo?(annevk)
Comment 11•6 years ago
|
||
Thanks a lot Thomas, that means https://github.com/whatwg/xhr/pull/224 fixes it (as we'll just leave the Content-Type header alone). No site so far suggests that serializing the MIME type with a space is also needed, but that's probably still what we should do I think. Hmm.
Flags: needinfo?(annevk)
Comment 12•6 years ago
|
||
I can confirm this is working now in 65.0a1.
Updated•6 years ago
|
Keywords: site-compat
Updated•6 years ago
|
Assignee | ||
Comment 14•6 years ago
|
||
Marion, I think this should actually be fixed in 64, since it was fixed in bug 1499136 (which is marked as fixed in 64).
Flags: needinfo?(mdaly)
Assignee | ||
Updated•6 years ago
|
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Updated•6 years ago
|
Flags: needinfo?(mdaly)
Updated•6 years ago
|
Updated•6 years ago
|
Component: DOM → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•