Closed Bug 1306472 Opened 4 years ago Closed 4 years ago
Bug 1307283 was mine; just chiming in here now that my bug is a dupe of this one. Note that this can be worked around by replacing the `src` with something like `about:blank`, which is the [fix] we used to make remotipart's file uploader work again, but it requires a code change on the server side, which no other browser cares about. : https://github.com/JangoSteve/remotipart/compare/v1.3.0...v1.3.1#diff-18f6f91c62fa429ea66ea59ceabcec7c
Two things: 1) Our new behavior is actually following the HTML spec, but clearly the spec is wrong here. I filed https://github.com/whatwg/html/issues/1895 to get the spec changed. 2) I strongly believe we should in fact fix this in 49, 50, 51. In fact, I think we should back out bug 1268047, since the spec it was aligning with is not only clearly bogus but doesn't even match the browsers it was claiming to match (see <https://github.com/whatwg/html/pull/1107#issuecomment-253558923>). Once the spec gets sorted out, we can see about aligning to whatever the new text is.
Assignee: afarre → bzbarsky
Status: NEW → ASSIGNED
[Tracking Requested - why for this release]: Breaks websites.
Comment on attachment 8800736 [details] [diff] [review] Back out bug 1268047, because the spec it tried to implement backs the web Approval Request Comment [Feature/regressing bug #]: Bug 1268047 [User impact if declined]: Some sites are broken and are telling users to use other browsers. [Describe test coverage new/current, TreeHerder]: This is backing out to our previous behavior, no new tests being added. [Risks and why]: I think this is pretty low-risk, since it just restores the Firefox 48 behavior and we were not aware of any sites having issues with that behavior. This is why I'm requesting 49 approval as well; this is causing real problems in the wild, and we should fix them ASAP. [String/UUID change made/needed]: None.
Pushed by firstname.lastname@example.org: https://hg.mozilla.org/integration/mozilla-inbound/rev/0f5505bf10d2 Back out bug 1268047, because the spec it tried to implement backs the web. r=smaug
Tracked for 50+ given the widespread impact.
Comment on attachment 8800736 [details] [diff] [review] Back out bug 1268047, because the spec it tried to implement backs the web Given the severity, let's uplift this to Aurora51 and Beta50 promptly and stabilize in those channels. This will give us more confidence on the fix in case we need to do a 49 dot release.
Hello Matt, once this lands on Nightly, could you please verify this issue is fixed as expected? Thanks!
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/9126be480c45 followup. Fix the timeout on the html/browsers/browsing-the-web/navigating-across-documents/014.html web platform test. r=bustage
Marking this as blocking 49 to indicate it is a driver for a 49.0.2 dot release. It would be good to verify the fix in the beta 50.0b7 build released this Friday. We could also land this on m-r now, and test from the treeherder builds.
Comment on attachment 8800736 [details] [diff] [review] Back out bug 1268047, because the spec it tried to implement backs the web Serious issue with 49, affecting several sites. Let's take this on mozilla-release for a 49.0.2 possibly for next week.
Attachment #8800736 - Flags: approval-mozilla-release? → approval-mozilla-release+
Uh.. no. That's not correct at all. This bug is fixed, which means we _will_ fire that load event in 50+, and in 49 as well if we ship a dot-release after this point.
I mean, maybe that's what the entry is trying to say, but that's definitely not the impression it's creating!
I know what's happening here; this doc should actually have been written for Bug 1268047. Somehow it slipped under my radar. Modified the description as follows: https://github.com/fxsitecompat/www.fxsitecompat.com/commit/2080b0c
This also affects fennec, right? I think this means we also need to release 49.0.2 for mobile.
> This also affects fennec, right? That's correct. :(
Hey, is it possible to add a regression test for this behavior somewhere so that Firefox won't regress in the future?
Yes. I plan to add a web platform test once the spec gets sorted out so I know what the test should test. If that takes more than about another week, I'll add a mochitest in the interim....
Well, there were tests added when the regressing bug landed, since that made us follow the spec, but the spec was wrong, and also those tests. I would expect us to get wpt tests for this once the spec issue is sorted out. Right now it is still unclear what the behavior actually should be - clearly not what the spec says, but what then, dunno. See https://github.com/whatwg/html/issues/1895 https://github.com/whatwg/html/issues/1896
Verified fixed in the latest Nightly.
Status: RESOLVED → VERIFIED
Updating flags based on Comment 35. We'll make sure this gets verified on 49.0.2 and 50.0b8 as well. ni?myself as a reminder.
I've managed to reproduce this bug on an affected build (49.0.1-build3, 20160922113459). This is verified fixed on: - 49.0.2-build1 (20161018030522) - 50.0b8-build1 (20161017130949) - 51.0a2 (2016-10-18) using Windows 10 x64, Ubuntu 14.04 x86 and Mac OS X 10.11.6. The onload event is fired, as expected.
Release Note Request (optional, but appreciated) [Why is this notable]: driver for dot release [Suggested wording]: [Links (documentation, blog post, etc)]: Web compatibility issue with file uploads (Bug 1306472) I'm happy to change the release note wording if someone can come up with a suggestion.
This bug is long-fixed. What makes you think this is the problem you're seeing?
Bug 1477821 tracks updating to the spec once that's sorted out.
You need to log in before you can comment on or make changes to this bug.