kepco.jp - Warning message due to pop-up blocker behaviour is present

[masayuki-nakano]

URL: https://kepco.jp/miruden/servicetop/newslist#3

Browser / Version: Firefox 91.0
Operating System: Windows 10
Tested Another Browser: No

Problem type: Something else
Description: User site of Kansai electric power corp warns Firefox is not useable due to popup blocker behavior difference
Steps to Reproduce:
The user website of Kansai electric power corp which is the electric power company of Kansai area in Japan warns that Firefox isn't usable due to popup blocker behavior difference and recommends using Chrome etc.

I tested the website briefly with logging in, but I couldn't find the unusable case, e.g., not opening new window (tab) as expected. However, they must have shipped the release for some users who complained about it. So, if it's possible, we should ask what or where does not work, and if that's what Firefox should fix for web-compat, we should do it.

View the screenshot

Browser Configuration

• None

From webcompat.com with ❤️

[masayuki-nakano]

The information of Kansai electric power said:

2021-08-18 (info)

Information for users using Firefox

We confirmed some issues which Firefox does not work if you use the latest version.
If you block popups from settings, you'll have trouble when you press login button etc.
We regret to say, if you use Firefox, you need to reset the popup blocker settings or use the other browsers (e.g., Google Chrome) instead.

[softvision-raul-bucata]

@masayuki-nakano We appreciate your report. For this issue, unfortunately, a special account is needed to sign in.

Test account creation requires valid data from an existing contract with the provider of services:

Having no valid sign-in credentials, we are not able to move forward with this issue.
If more information is provided (test account credentials can only be provided by mail for security purposes, as the comments here are made public,/ attach logs/errors), in-depth testing can be performed, so please feel free to reopen or comment on the issue and we'll have a thorough look at it.

Suggestion: Try clearing cache/data/cookies, disable Ad-blocker (if available), or use a clean profile, and check again? Also, have the required cookies have been accepted for this page?

[masayuki-nakano]

Sure. I've not found any problems with default popup blocker settings. So, I guess that it's a problem with custom settings. However, according to their message, it seems that it's caused by recent behavior change of Firefox. I'll try to reproduce some trouble with changing popup blocker settings. I wonder, do Mozilla have a way to add the domain to the allow-list of popup blocker if I find a situation but it's caused by design?

[softvision-raul-bucata]

@masayuki-nakano Have the default settings of the browser been changed? Do you also have any add-ons/ extensions installed in the browser? Could you please provide any logs/console errors?

[masayuki-nakano]

@masayuki-nakano Have the default settings of the browser been changed? Do you also have any add-ons/ extensions installed in the browser? Could you please provide any logs/console errors?

My point is, I still do not see any problems with default settings, but such important company's website says that "Firefox may not be available, use another browser". If it's caused by recent change of our popup blocker, and it means that it may cause serious web-compat issue for some websites. Therefore, I reported this fact here.

It's sad that nobody who does not live in this area cannot test this site due to requiring the customer number. So, I'll try to find the problem(s) when I have spare time. But if somebody can test this with seeing this report, or contact the company, it'd be nice. (The information which you can show in member's page is too sensitive. So, I cannot provide my account information...) I'd like to move this forward during the soft code freeze in next week.

[softvision-raul-bucata]

@masayuki-nakano We understand being unable to provide account info. Could you please provide some logs, console errors? This way our team can look more deeply into the issue and maybe find the culprit, without needing the login credentials.

@karlcow Any luck in testing this issue from your location? (maybe we are lucky with some valid test credentials)

[karlcow]

@softvision-raul-bucata masayuki is working for Mozilla.

I'm not living in Kansai (specific area of Japan), so that will not be possible for me to diagnose.
The message in https://kepco.jp/miruden/servicetop/newslist#2

And indeed on Firefox Nightly 94 latest version, Pop up blockers are activated by default. So this is one of the reason. But usually there's a message informing about the block, except if someone said do not show me any messages.

[softvision-raul-bucata]

Based on the provided info by @masayuki-nakano, this will be moved to needsdiagnosis for further investigations

[masayuki-nakano]

Sorry for the really long delay. I got a chance to be back here today.

I find a page which can reproduce that popup blocker blocks the popup on Firefox.

1. Go to https://kepco.jp/gas/ryokin/gasdenki_simu
2. Fill the login form in the right side bar (under "はぴeみる電")
3. Click "ログイン" (login) button under the form

It calls login(0) from a click event listener:

var login = function(mode){
  var obj = document.getElementById("openId");
    switch(mode) {
      case 1 : obj.value = "Twitter"; break;
      case 2 : obj.value = "FaceBook"; break;
      case 3 : obj.value = "Google"; break;
      case 4 : obj.value = "Yahoo"; break;
      default : obj.value = "Corporate"; break;
    }
    var frm = document.getElementById("mainform");
    frm.method = "post";
    frm.action = "https://kepco.jp/miruden/ServiceTop";
    frm.target="miruden";
    frm.submit();
}

So, I'm not sure why this is blocked by the popup blocker since it's in a user interaction. @EdgarChen do you have any idea about this?

[karlcow]

$(function () {
$('#mirudenLogin').on('click', function () {
login(0);
return false;
});
});

and

<li class="loginButton currentOwner"><a id="mirudenLogin" style="cursor:pointer;" class="current">ログイン</a></li>

a instead of button but that's probably not the issue.

when clicking on the login, the browser sent a pop up at the top of the viewport

if I allow the site to open a new tab, Firefox does it and redirect to the page https://kepco.jp/miruden/ServiceTop

and the second time I tried. I got redirected to https://kepco.jp/miruden/servicetop/login

The new window opening is happening here.

function WebForm_SaveScrollPositionSubmit() {
    if (__nonMSDOMBrowser) {
        theForm.elements['__SCROLLPOSITIONY'].value = window.pageYOffset;
        theForm.elements['__SCROLLPOSITIONX'].value = window.pageXOffset;
    }
    else {
        theForm.__SCROLLPOSITIONX.value = WebForm_GetScrollX();
        theForm.__SCROLLPOSITIONY.value = WebForm_GetScrollY();
    }
    if ((typeof(this.oldSubmit) != "undefined") && (this.oldSubmit != null)) {
        return this.oldSubmit();
    }
    return true;
}

specifically

        return this.oldSubmit();

yes typing this.oldSubmit() on the console opens a new tab with the login.

note that this is an old script.

var __nonMSDOMBrowser = (window.navigator.appName.toLowerCase().indexOf('explorer') == -1);

The script in there looks awfully similar to https://bugzilla.mozilla.org/show_bug.cgi?id=498447

[EdgarChen]

Recently, there is a change on the popup blocker (bug 1733052) which makes most of the async cases (e.g. calling window.open when a promise is fulfilled) work. Not sure if this is the same case, but @masayuki-nakano, @karlcow, could you help to test whether this still happens on 95? Thanks!

[EdgarChen]

NM, I just tested it, the login is still blocked on the latest Nightly, I will take a look.

[karlcow]

I let @masayuki-nakano test as it doesn't seem to reproduce for me.

[masayuki-nakano]

I still reproduce it on both release and nightly channels. (And the website is too slow today, something happens?)

[EdgarChen]

I think I know where the issue is: in theory, bug 1733052 should make most of the async cases work (e.g. calling window.open when a promise is fulfilled), as the popup blocker would fallback to the new user activation model when there is no popup state on the stack. However, the popup state would be propagated to the microtask after the event handler, if the promise is scheduled to that microtask the popup blocker ends up doesn't fall back to the new user activation model. This is kinda a bug of old popup state propagation.

For the long term, we will move everything to the new user activation model and remove the popup state.
For the short term, we could try to fix the popup state propagation bug, so that the popup block would fall back to the new user activation model for this case. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1739655.

[karlcow]

Duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1739655
Thanks Edgar.

[karlcow]

@EdgarChen does it relate to https://bugzilla.mozilla.org/show_bug.cgi?id=1657738
whatwg/html#5872
and https://groups.google.com/a/chromium.org/g/blink-dev/c/q6ybnmxxvpE/m/2snoh6wkAgAJ

[EdgarChen]

No, it's different. They are more about how the popup window should be shown on UI (e.g. with or without location bar .. etc). And this is more about do we allow to open a popup (would the window.open be blocked by popup blocker?) under certain situations.