1902405 - soffice.11st.co.kr - Firefox is unsupported browser warning

Status: ASSIGNED

(Web Compatibility :: Site Reports, defect, P3)

Description

[Ksenia Berezina [:ksenia]]

Environment:
Operating system: Windows 10
Originally reported Firefox version: Firefox 126.0
Last reproduced with the following UA: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:126.0) Gecko/20100101 Firefox/126.0
All platforms issue was reproduced on: windows,mac,linux,android

The following message is detected on the page:
크롬 브라우저 사용을 권장합니다.

The issue was detected while running a crawler on top 100k sites globally

Comment 1

[Sky Schubert [:skyschub]]

Mass-assigning diagnosis-team to webcompat for "Firefox is not supported" bugs that don't already have a team assigned. This action is done by a script. For your convenience, feel free to filter your bugmail with 559a9604-41ec-11f0-9ec6-f3f21dcd7cf2.

Comment 2

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

Attachment: Bug 1902405 - add a CSS intervention for soffice.11st.co.kr to hide unsupported browser warning; r?denschub

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/dbbf9718b365
https://hg.mozilla.org/integration/autoland/rev/42c88dc64b51
add a CSS intervention for soffice.11st.co.kr to hide unsupported browser warning; r=denschub,webcompat-reviewers

Comment 4

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/42c88dc64b51

Comment 5

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

On Android they no longer seem to show any message, so let's disable the intervention on Android.

Comment 6

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

Attachment: Bug 1902405 - disable our webcompat intervention for soffice.11st.co.kr on Android where it is not needed; r?denschub

Comment 7

[Daniel Holbert [:dholbert]]

hmm, the intervention-stylesheet might not be getting injected on Windows for some reason. I see the browser-not-supported message showing up there, despite the intervention being enabled (in a fresh profile and my regular browsing profile; tested Firefox 142 release and Firefox 144.0a1 Nightly, after confirming the intervention shows up and is enabled in about:compat in both of those versions).

twisniewski, mind taking a look at that while you're poking here? Maybe that's something that's worth fixing at the same time as the disable-on-Android patch?

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/1d33d14b5290
https://hg.mozilla.org/integration/autoland/rev/0f309be9b809
disable our webcompat intervention for soffice.11st.co.kr on Android where it is not needed; r=webcompat-reviewers,dholbert

Comment 9

[amarc]

https://hg.mozilla.org/mozilla-central/rev/0f309be9b809

Comment 10

[Thomas Wisniewski [:twisniewski][on PTO until July 6]]

I'm not seeing the unsupported message on my Windows machine, so if it's still having trouble for you Dan, please let me know.

Comment 11

[Daniel Holbert [:dholbert]]

Attachment: screenshot

Yeah, I'm still seeing the unsupported browser version in Windows 11 in Firefox 143 in BrowserStack. It's the blue bar at the top here. I confirmed that the intervention is still shown and enabled on about:compat in this Firefox session.

Comment 12

[Daniel Holbert [:dholbert]]

Huh, I see the intervention applying properly (and hiding the bar) on my local Windows 11 installation though... It's working properly in Windows 10 with Firefox 143 on BrowserStack too. Poking further to see what's going on in the session where I'm seeing the message...

Comment 13

[Daniel Holbert [:dholbert]]

So in the affected environment:

• The intervention's stylesheet is there in the extension, and accessible via its moz-extension URI:
  moz-extension://9a310967-e580-48bf-b3e8-4eafebbc122d/injections/css/bug1902405-soffice.11st.co.kr-hide-browser-warning.css
  ...but it's not getting injected into this page for some reason.

• However: if I wait for a little while (several minutes), then it starts injecting and working properly on subsequent tab-reloads.

Is there sometimes some sort of delay before injections start working?

Comment 14

[Daniel Holbert [:dholbert]]

OK, yeah - looks like what I'm seeing is just some sort of 10+-second delay at first startup[1], before interventions get enabled. If I wait 30 seconds or so, then I get expected-results on the browserstack environment.

So: the intervention is functioning properly here.

[1] Here's a profile I captured in BrowserStack: https://share.firefox.dev/4mGkV8v (and note that I started profiling a few seconds after connecting to BrowserStack, so mentally add 5+ seconds to the timestamps in the profile, to get my "real-world-experience" timeline). At around 7.75s in the profile (so maybe t=13s in my real-world experience), the WebExtensions process shows "_onEnabledStateChanged" which seems to kick off some activity that includes various functions with names like _enableInterventionNow. I think that's the important thing here for getting the intervention to be active. I'm not sure why there's such a long delay, but maybe BrowserStack happens to be using a Firefox user-profile with stale data for that extension, and we're blocked on remote-settings causing the webcompat extension to dynamically update or become enabled, or something like that.

Comment 15

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

The leave-open keyword is there and there is no activity for 6 months.
:twisniewski, maybe it's time to close this bug?
For more information, please visit BugBot documentation.