Open Bug 1863713 Opened 1 year ago Updated 11 months ago

omavero.vero.fi - Pop-up opening exception rule does not work

Categories

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

Firefox 119
Desktop
Windows 10
defect

Tracking

()

Tracking Status
firefox119 --- affected

People

(Reporter: rbucata, Unassigned)

References

(Depends on 1 open bug, )

Details

From github: https://github.com/webcompat/web-bugs/issues/129453.

<!-- @browser: Firefox 119.0 -->
<!-- @ua_header: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0 -->
<!-- @reported_with: unknown -->

URL: https://omavero.vero.fi/

Browser / Version: Firefox 119.0
Operating System: Windows 10
Tested Another Browser: Yes Chrome

Problem type: Something else
Description: Popup opening exception rule does not work
Steps to Reproduce:
Two issues. First, Firefox prevents the opening of popups on this site, the self-service of the Finnish Tax Authority. Chrome does not prevent those popups. The "popups" are PDF documents, opened in new browser tabs.

Second, Firefox offers the option to add an exception rule to Allow popups from this site in the future. Choosing this adds to Firefox Settings > Allowed websites - Pop-ups an exception rule for Website https://omavero.vero.fi with the status of Allow. However, this exception rule does not have any effect. Firefox does remember user choice until the end of the browsing session (even if the exception setting is removed), but does not honor it upon next browsing session (even if the exception rule is still there).

In other words, popup exception rules are not working, at least not in this site. This has been a bug in Firefox for years. Hope with this report you'll finally get someone to fix it.

Note that accessing the part of the website where popups are used basically requires a Finnish citizenship or resident - Finnish online banking credentials, and an account with the national Tax Authority. One page, after logging in, is "Communication > Decisions and letters" (in Finnish "Yhteydenpito > Päätökset ja kirjeet"). A table is presented, and upon clicking the title of a letter/decision (at the left):

In Chrome/Vivaldi: Opens a popup directly (it doesn't get stuck in automatic popup prevention, which is great)

In Firefox: A new browser tab is opened, which includes the following things. At the top there's a (narrow and easily missable) Firefox native bar telling that a popup was prevented from opening, and options like "Allow pop-ups from <this site>" and "Show <popup URL>". As mentioned, the Allow from site does work for the browser session, but has no permanence beyond that. It also does not show the popup that was blocked, requiring an extra click on the page for that.

Because that narrow top bar is easy to miss (for understandable reasons), it's good that the web page itself tells the user that the problem is the web browser being overly zealous in blocking popups, and the browser should be instructed to allow them.

A list of the issues:

  1. The popup blocker is too aggressive in this case; Chrome and Vivaldi handle this better, not blocking this very wanted popup

  2. When choosing to Allow popups from this site, two specific issues occur. First, the exception rule to allow popups from this site is applied for the duration of the browsing session even if the rule is removed from Firefox settings. So the mechanism for storing and remembering an exception is not tied to the exception rule but something else.

  3. Second, the exception rule in Firefox settings does nothing (at least on this website) - it is not honored in the next browsing session, and the user is once again presented with the web page and browser bar telling them that a popup was blocked, would you like them to be allowed in the future (and having to both click that to allow them during the rest of this browsing session, and make additional clicks to open the first blocked popup).
    <details>
    <summary>View the screenshot</summary>
    <img alt="Screenshot" src="https://webcompat.com/uploads/2023/11/ea56466b-55b1-4fd0-8679-0419b40ac113.jpg">
    </details>

<details>
<summary>Browser Configuration</summary>
<ul>
<li>None</li>
</ul>
</details>

From webcompat.com with ❤️

Change performed by the Move to Bugzilla add-on.

The issue was reported via the webcompat.com reporter. Since the issue is related to the "Allow pop-ups" setting, we have moved the issue. Please feel free to move the issue to the correct Product and Component.

OS: Android → Windows 10
Product: Core → Firefox
Hardware: Unspecified → Desktop
Version: unspecified → Firefox 119

Emilio, do you have any sense whether this is a bug in the popup blocker, or if it's simply that the popup blocking algorithm is different than the other browsers and our heuristics happen to get tripped by this particular site?

Flags: needinfo?(emilio.alvarez96)

Redirect a needinfo that is pending on an inactive user to the triage owner.
:mossop, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio.alvarez96) → needinfo?(dtownsend)

(In reply to Dan Mosedale (:dmosedale, :dmose) from comment #2)

Emilio, do you have any sense whether this is a bug in the popup blocker, or if it's simply that the popup blocking algorithm is different than the other browsers and our heuristics happen to get tripped by this particular site?

Please needinfo the right Emilio! :)

I know our popup blocker is sometimes different from other browsers, but it's hard to say what the right cause is without digging into it. At a glance, accessing https://omavero.vero.fi/ requires some authentication. Olli, maybe you can take a quick poke?

Flags: needinfo?(dtownsend) → needinfo?(smaug)

First time I try to open a pdf there, OmaVero itself notifies user that popup was blocked and tells what to do. And when an exception is added it stays there even after restarting the browsers. I tested Nightly.

edgar, do you recall if we have a bug open to make popup blocking use user gesture flag (transient one, I think) ?

Flags: needinfo?(smaug) → needinfo?(echen)

(In reply to Olli Pettay [:smaug][bugs@pettay.fi] from comment #6)

edgar, do you recall if we have a bug open to make popup blocking use user gesture flag (transient one, I think) ?

I believe bug 1656444

Flags: needinfo?(echen)

Moving this to the component of the bug that it depends on, since it doesn't really belong in Firefox General.

Component: General → DOM: Core & HTML
Product: Firefox → Core

Aligning the severity to bug 1656444.

Severity: -- → S3
You need to log in before you can comment on or make changes to this bug.