1396396 - Page is not refreshed after form submission

Status: UNCONFIRMED

(Core :: DOM: Forms, defect, P5)

Description

[Johannes]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:52.0) Gecko/20100101 Firefox/52.0
Build ID: 20170802111520

Steps to reproduce:

1. Open the form at http://sagamusix.untergrund.net/fileupload-2.htm
2. Select a small file for upload and submit it


Actual results:

Firefox 52 ESR and Firefox 55 upload the file to the server as expected, but they never show the resulting page. This HTML snippet is extracted from a server application and I was able to verify that the resulting page is being served to the browser, but it was never displayed there.


Expected results:

Like in Firefox 54, the resulting page (Saying "Done!") should be shown.

Note that this might be closely related to bug #1396395 which I submitted.

Comment 1

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Johannes, thanks for reporting this. Would it be possible that you get a regression window for us according to [1]? 

[1] https://blog.nightly.mozilla.org/2017/06/07/using-mozregression-on-windows/

Comment 2

[Johannes]

After closer inspection, it seems like uBlock Origin needs to be installed to trigger this bug. Possibly an add-on issue, but the related crash in bug #1396395 indicates that Firefox might be doing something wrong here as well.

Comment 3

[Johannes]

After further observation, the behaviour occurs only if uBlock Origin and either one of the following legacy add-ons is installed:
* BetterStop 1.0.1
* Image Zoom (ugly fixes) 0.0.1
* Web Developer 1.2.13

See https://github.com/gorhill/uBlock/issues/2982#issuecomment-327463631

Comment 4

[GµårÐïåñ]

I am wondering why the access to the referenced bug #1396395 is denied?

Comment 5

[Johannes]

Because it's potentially relevant to security.

Comment 6

[GµårÐïåñ]

And? SO no one is allowed to review security related bugs that may affect them? How is that going to help anyone mitigate an issue or contribute to it if you can't even see it? Or in the least a developer has a right to review it and see what it is so they can make informed decisions. This lacks transparency and if it is so bad that it has to be hidden, why isn't it fixed?

Comment 7

[Johannes]

It is a common practice to report potential security issues privately, also for Mozilla. This gives the software developer a chance to fix the bug before it is widely known or exploited by malicious people. However, this ticket is the wrong place to discuss such security practices.

Comment 8

[GµårÐïåñ]

I am fully aware of that and have no objection to it but how are developers supposed to be able to review the bug to fix it if they can't even access it. I agree that here is probably not the best place to discuss this but where would you suggest that take place? I am open to suggestions. Because it is difficult to evaluate the impact of a bug on our code if we can't even see what it is and how it occurs so we can mitigate it or even contribute to fixing it. What arbitrary standard is in place to decide who sees the and who doesn't?

Comment 9

[Johannes]

The security team should have a look at the bug first (they have access to it) and assess whether it's really relevant to security or just a "harmless" crash. If it's the latter they can still open the bug to other developers.

Comment 10

[GµårÐïåñ]

I understand that, fine. But if it is a security bug, then who decides who sees it? That's my question, how do they decide which developers see it? I have been developing and contributing to multiple repositories (two of which are core security addons) for over a decade and many of us can't access the same information that other members of our team do, so we are put at a distinct disadvantage to be able to follow the progress on it so we can effectively mitigate it or plan a fix for it. I can't see anywhere where one can even ask to be included or find out why they weren't included to begin with. Do you know, since you seem to be able to access something the rest of us can't? If so, would be great if you can share and I will take it up with them.

Comment 11

[Johannes]

Sorry, I am the wrong person to ask. All I did was filing the bug as "security relevant", which hides it automatically. This is an option on the bug submission form that anyone can check if they think their bug is critical.
Maybe the Mozilla mailing lists would be a good place to ask for further information on who gets to see those reports and how to get into that list? I'm just guessing, as I'm merely a Firefox user, not a developer.

Comment 12

[GµårÐïåñ]

Understood, thank you.

Comment 13

[Andrew Overholt [:overholt]]

(In reply to Johannes from comment #3)
> After further observation, the behaviour occurs only if uBlock Origin and
> either one of the following legacy add-ons is installed:
> * BetterStop 1.0.1
> * Image Zoom (ugly fixes) 0.0.1
> * Web Developer 1.2.13
> 
> See https://github.com/gorhill/uBlock/issues/2982#issuecomment-327463631

baku, do you have any thoughts here? I'm not sure what we can do given the add-ons trigger this ...

Comment 14

[Andrea Marchesini [:baku]]

This bug cannot be reproduced with FF57 because the legacy addons cannot be installed.
I would like to wait what ublock developers say about this bug.

Comment 15

[Johannes]

Giving the findings in bug #1396395 (which is now public), it sounds to me like fixing that bug properly could also resolve this bug here.

Comment 16

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Given this reproduces only if certain legacy add-on installed, moving this into P3 backlog.