1912721 - ebusiness.anb.com.sa - Page becomes unresponsive shortly after trying to enable location

Status: NEW

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

Description

[Calin Tanase]

Environment:
Operating system: Windows 10
Firefox version: Firefox 129.0/131

Steps to reproduce:

1. Go to https://ebusiness.anb.com.sa/corp/AuthenticationController?FORMSGROUP_ID__=AuthenticationFG&__START_TRAN_FLAG__=Y&FG_BUTTONS__=LOAD&ACTION.LOAD=Y&AuthenticationFG.LOGIN_FLAG=1&BANK_ID=ARNBSARI
2. Click ok on the prompt.
3. Check the box to remember the decision and click ok again.
4. Try allowing the location.
5. Observe the behavior.

Expected Behavior:
Location is enabled.

Actual Behavior:
Page becomes unresponsive and memory/cpu usage spikes up.

Notes:

• Reproduces regardless of the status of ETP
• Reproduces in Firefox Nightly, and Firefox Release
• Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/140220

Comment 1

[Calin Tanase]

Attachment: memory usage.png

Comment 2

[Calin Tanase]

I was not able to record a performance profile because the browser does not respond to any commands. I was able to close the browser only with task manager.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

This bug was moved into the Performance component.

:ctanase, could you make sure the following information is on this bug?

• For slowness or high CPU usage, capture a profile with http://profiler.firefox.com/, upload it and share the link here.
• For memory usage issues, capture a memory dump from about:memory and attach it to this bug.
• Troubleshooting information: Go to about:support, click "Copy raw data to clipboard", paste it into a file, save it, and attach the file here.

If the requested information is already in the bug, please confirm it is recent.

Thank you.

Comment 4

[Bas Schouten (:bas.schouten)]

The Performance Impact Calculator has determined this bug's performance impact to be medium. If you'd like to request re-triage, you can reset the Performance Impact flag to "?" or needinfo the triage sheriff.

Platforms: Windows
Impact on browser: Renders browser effectively unusable
Impact on site: Causes noticeable jank
Websites affected: Rare
[x] Able to reproduce locally

Comment 5

[Bas Schouten (:bas.schouten)]

Moving to the appropriate component and adding a profile.

https://share.firefox.dev/3Zfs7QS

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

The component has been changed since the backlog priority was decided, so we're resetting it.
For more information, please visit BugBot documentation.

Comment 7

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

It took most of the time in CapabilityAccessManagerClient.dll from Windows, triggered by:

  ComPtr<IAppCapabilityStatics> appCapabilityStatics =
      CreateFromActivationFactory<IAppCapabilityStatics>(kAppCapabilityGuid);

Comment 8

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

dom/geolocation/GeolocationSystemWin.cpp is more of desktop integration and should go widget/ IMO, and we probably can get more eyes there.

Comment 9

[Ray Kraesig [:rkraesig]]

For convenience of reference, the code quoted above is at: https://searchfox.org/mozilla-central/rev/55f2ada1564baaeebd69d277b38737961a3ca5f3/dom/geolocation/GeolocationSystemWin.cpp#43-44

dom/geolocation/GeolocationSystemWin.cpp is more of desktop integration and should go widget/ IMO, and we probably can get more eyes there.

That's true if this is a Windows issue, but I suspect it might not be. (Has anyone tested on Mac or Linux?)

The page seems to be extraordinarily ill-behaved — it spams the user with alert()s demanding they enable geolocation, but those alerts themselves prevent the user from doing so until and unless they block alerts entirely. Additionally, I can partially reproduce the issue even when blocking geolocation services. I suspect the page is just hammering Firefox with geolocation requests regardless of the state of geolocation approval.

Ni?ing :handyman for geolocation expertise nonetheless.

Comment 10

[David Parks [:handyman]]

Thanks :saschanaz and :rkraesig for looking at the cause. It seems, based on comment 0, that the issue is reported against 129 release -- but the cited Windows code only went in for 131 (actually went into nightly last week). :rkraesig might have a point about the platforms. Leaving NI open -- I'll dig into this soon.

(FYI, GeolocationSystemWin.cpp is in the Widget/Win32 component, as per moz.build.)

Comment 11

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Adding see also for the IAppCapabilityStatics thing, for now.

Comment 12

[Gian-Carlo Pascutto [:gcp]]

Based on comment 9, this is not an S2.

Comment 13

[Haik Aftandilian [:haik]]

The problem is reproducible on Mac (M3 MacBook Pro). I tested today and encountered the same behavior as Ray in comment 9. I saved two profiles below. One where I attempted to give the site geolocation access but couldn't and one with geolocation disabled in Firefox settings. With location disabled, the unresponsiveness wasn't noticeable with this site, but that may be dependent on having a fast computer and more testing is needed.

While the site is user-hostile, it's a valid test case. On the surface, it appears we should throttle geolocation requests to avoid this type of spamming where the whole browser becomes unresponsive. We already throttle the prompts with the checkbox to let the user choose to block more prompts from the site. Alternatively, we might want to explore making the geolocation UI persist in a stable fashion when there are repeated geolocation attempts (like Chrome). The key would be to make sure the excessive processing in the parent process is avoided.

Addressing this at the DOM::Geolocation level seems right, but this bug has already bounced from that component. Note this is one of the "WebCompat Prioritized Core Bugs" we're tracking.

@Hsin-Yi, could someone from your team weigh in on this? Should this be addressed at the DOM or platform level, or both?

--

My test results:

The site is user-hostile with its 1) repeated prompts and then 2) repeated geolocation requests, but it causes Firefox to become unresponsive. In my case, I couldn't interact with other tabs while having the problematic tab open or for a period of multiple minutes after closing the tab. I tested this on Mac Chrome and it didn't appear to impact the browser. In Chrome, the geolocation popup persists and is easy to click compared to our implementation where it is flickering and not-clickable due to the repeated requests.

Profile 1: https://share.firefox.dev/3WcFhMi
Profile 2 (Location disabled): https://share.firefox.dev/4gQpOty

Profile collection steps:

1. Open test case in new tab
2. Click OK on the site prompt instructing the user to enable geolocation
3. The prompt immediately returns
4. Click Don't allow ebusiness.anb.com.sa to prompt you again
5. The Firefox geolocation is appearing/disappearing rapidly and can't be clicked
6. After attempting to click Allow for a period of time, close the tab.
7. Unresponsiveness continues on other tabs

For the second profile, geolocation was disabled by selecting "Block new requests asking to access your location" in the Location panel in about:preferences#privacy.

Comment 14

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Both profiles took a lot of time in checkLoc() site JS function which calls navigator.permissions.query({name:'geolocation'}), and if the status is still prompt, then it calls alert() and then calls itself again, which effectively causes infinite recursive call when alert() becomes no-op. Such rapid call causes parent process DoS with the repeated permission check via PContent.

So two things:

• We need IPC backpressure for permission API, described in bug 1885077. Or some permission caching mechanism.
• We should consider returning granted instead of prompt for one-time geolocation permission grant. (bug 1719651)

Comment 15

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

Thanks Kagami for the details in comment 14. :) I don't think I have anything more to add on top of that or have any other DOM Core members who can chime in as quickly as Kagami.

Comment 16

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Resetting priority/severity for retriage from permission manager owners.

Comment 17

[Emma Zühlcke [:emz]]

Tim, could you elaborate why you think this fits into Site Permissions? It seems more related to the permission API to me, so Permission Manager or DOM seems more appropriate?

Comment 18

[Tim Huang[:timhuang]]

I thought the Permission API was part of the Site Permissions module. It might be more appropriate for the DOM.

Comment 19

[Emma Zühlcke [:emz]]

Site Permissions is Desktop permissions code, which is mostly frontend + temporary permission logic.

Comment 20

[Henri Sivonen (:hsivonen) (not reading bugmail until 2026-07-27)]

This is bad on Linux, too.

Since it isn't particularly common for this problem to show up, S2 seems too high, so I'm setting this as S3. I think this deserves more attention than an average S3/P3, though.

Edgar, while this isn't about user activation per se, do we already have some rate limiting functionality that could be applied here?

Comment 21

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

We landed some changes in geolocation recently. I am curious if this issue is still valid. Thanks.

Comment 22

[Raul Bucata]

The issue is still reproducible on the latest Nightly. There is a pop-up present on the page that shows you how to enable the location services from the browser. Once you do that, the location permission toolbar prompt is triggered, which glitches and causes the page to not respond.