Blockable content preventing form submission not overridable
Categories
(Firefox :: Protections UI, defect)
Tracking
()
People
(Reporter: jaggz.h, Unassigned)
Details
Attachments
(1 file)
|
25.11 KB,
image/png
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Steps to reproduce:
My own page (non-ssl), where I am trying to submitting HTML+javascript to my own site, through a standard textarea in a form, shows the "Blockable content detected on this site" message. There is no ability to whitelist the site.
Actual results:
Submission of form sits there trying forever. This could be my own site failing to handle whatever is not being transmitted by firefox due to the content blocking.
Expected results:
There should be an option to whitelist the current site. There is no shield to click on. (The page is NOT https, if that is related to the non-display of a shield.)
Barring that, there could be an ability to manually add a site to the whitelist area in settings.
More information on what's being blocked might be useful, but in this case I figure it's the javascript that's either presented in my form field when loaded from my page, or what I'm entering at the time.
Thank you for filing this bug.
Would you link to an example such as on CodePen which demonstrates the form you created and are running into problems with?
Hi Emma,
You might be able to see an example in this very bugzilla page.
(My own is someone's project so I'd have to work on it to have something postable).
However, the main issue is that adding exclusions is not possible.
The option shown in the documentation is not available from the Shield menu. See attached snapshot.
Documentation shows there should, I believe, be an option "Turn off blocking for this site" there:
https://support.mozilla.org/en-US/kb/content-blocking#w_turn-content-blocking-off-on-individual-sites_2
The direction to the whitelist in Prefs -> Privacy, then "Manage Exceptions" doesn't help, since there's no way to add an exception by hand -- only removal is available there.
Obviously the "Turn off blocking for this site" should be available and working.
And, as a separate potential feature, I think it'd be good to allow the manual adding of exclusions to the "Manage Exceptions" area. I can imagine admins of institutions/govt. adding several sites there, without visiting each one and manually picking the "Turn off blocking ..." option for each, but this would be a supplemental feature I guess.
Comment 4•6 years ago
•
|
||
Hi, This issue might be a duplicate of Bug 1541050 but I'm not entirely sure, The turn off Blocking for this site button should be displayed when Cookies are detected on the page.
Comment 5•6 years ago
|
||
"Blockable" in this context just means there are cookies on the site. You're not blocking anything, thus we don't offer the unblock button, as a way not to confuse users into thinking clicking it would affect anything on the page. The issues you're seeing are not with content blocking, as far as I can tell. If you have further evidence that this is a Firefox bug, please follow up with that.
I know this is confusing to you, but the opposite might be confusing to other people, so we have to find a balance here.
I've whittled it down to this, when typed into a <textarea>, that won't submit:
<script type='text/javascript'>
function getcookie(name) {
var cookiestr=RegExp("" + name + "[^;]+").exec(document.cookie);
}
</script>
If I throw an x's in the line it'll submit:
var cookiestr=RegExp("" + name + "[^;]+").exec(documentx.cookie);
I can't reproduce it on CodePen though.
Differences between codepen and my page:
- Mine is non-ssl
- Mine has a cookie for login
Otherwise, the page is very simple, with no scripts running in it.
Here's the codepen I created for it, but I can't find out how to disable the redirect to https to pursue if it's a combination of non-ssl + that line in the form contents, or to continue from there:
https://codepen.io/anon/pen/MdMEWX
Comment 8•6 years ago
|
||
I don't really understand the problem and I'm not sure how this is related to content blocking. Maybe file a new bug in a Core component?
Description
•