Closed Bug 1639821 Opened 4 years ago Closed 17 hours ago

WebRTC sharing indicator displays an XML parsing error

Categories

(Core :: XPCOM, defect, P3)

Product:
Core
Component:
XPCOM
Platform:
Desktop
All
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr91 --- wontfix
firefox-esr102 --- wontfix
firefox-esr115 --- wontfix
firefox84 --- wontfix
firefox97 --- wontfix
firefox98 --- wontfix
firefox101 --- wontfix
firefox102 --- wontfix
firefox103 --- wontfix
firefox124 --- fixed

People

(Reporter: dotnetifier, Assigned: jesup)

References

(Depends on 1 open bug)

Details

(Whiteboard: [necko-triaged][workaround in comment 118])

Attachments

(1 file)

xml-parsing-error.png
281.97 KB, image/png
Details
Attached image xml-parsing-error.png —

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:77.0) Gecko/20100101 Firefox/77.0

Steps to reproduce:

I opened a website that wanted to use my microphone. I allowed the microphone permission (twice, because apparently Discord does that).

Actual results:

A size window opened that displays an XML Parsing error. Full details:

XML Parsing Error: no root element found
Location: chrome://browser/content/webrtcLegacyIndicator.xhtml
Line Number: 1, Column 1:


^

The window has a size of 581 x 244 (width x height), and is located at the top left of my primary monitor. The window is always on top (which the indicator should do), but due to its size it is incredibly annoying.

Expected results:

The usual sharing indicator should have been displayed.

OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Hi Paul,

I was not able to reproduce this issue using Firefox Nightly 78.0a1 or Firefox Release 76.0.1

Could you check if this issue also occurs in safe mode? Here is a link that can help you with that:
https://support.mozilla.org/en-US/kb/troubleshoot-extensions-themes-to-fix-problems#w_start-firefox-in-safe-mode

If it still occurs in safe mode, try making a new profile and checking again. Here is how to do this:
https://support.mozilla.org/en-US/kb/profile-manager-create-remove-switch-firefox-profiles#w_start-the-profile-manager-when-firefox-is-closed

Thank you for reporting!

Flags: needinfo?(dotnetifier)

Hi Peter,

I'm no longer able to reproduce the bug myself. Although I could consistently reproduce it when I first created this report (even after reboots), I'm no longer able to reproduce it at all now.

I'm going to assume this was a one-time bug then. Apologies for wasting your time here.

I am not familiar with the process around bugs that aren't reproducible -- can I close this somehow?

Flags: needinfo?(dotnetifier)

According to Comment 2 this issue does no longer occur so I'm going to close it.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → WORKSFORME

Hey all,

I have the same error. Exact same circumstance in which it happened, windows 10, logged onto Discord that wanted to use my mic and the message appeared in the top left of my screen. The only difference is that I am running FireFox 79.

This just started happening to me too.

This is also reproducible on Firefox 84.0.2 (64-bit) running on Mac OS Mojave.

[Tracking Requested - why for this release]:

status-firefox84: --- → affected

Reopening since the issue seems to have come back.

Jorge, could you check if it also occurs on the latest Firefox Nightly? You can download it from here:
https://www.mozilla.org/en-US/firefox/channel/desktop/

Thank you!

Status: RESOLVED → REOPENED
Component: Untriaged → Site Permissions
Ever confirmed: true
Flags: needinfo?(jorge)
Resolution: WORKSFORME → ---

We no longer show a webrtc indicator window on Windows and macOS since Bug 1665490. That's since Firefox 83.
However, I can't reproduce with privacy.webrtc.legacyGlobalIndicator = true on release or nightly either.

Hi Peter, Paul,

I was not able to reproduce it on the latest Nightly. And it seems not to be happening any more on Firefox 84.0.2 after re-starting the app.

Before, I could reproduce it very easily by just visiting https://test.webrtc.org/ or initiating any video conference (Chime, Google Meetings, ....) from the browser.

Flags: needinfo?(jorge)
Summary: Sharing indicator displays an XML parsing error → WebRTC sharing indicator displays an XML parsing error

Hi!

Could you guys also verify this on the latest Firefox 84.0.2 and latest Firefox Nightly 86.0a1?

Thank you!

Flags: needinfo?(timothycoffelt)
Flags: needinfo?(nineohnine)

I started seeing this today, even though privacy.webrtc.legacyGlobalIndicator has its default value of false. I am on Firefox 85.0.2 (64-bit), on Windows 10. I noticed on discord, but the test.webrtc.org website also causes the error popup.

I don't think it started after an upgrade. I haven't checked yet if it goes away after a restart, in case there's something I can help debug while it's reproducible.

Correction, the error I see is slightly different:

XML Parsing Error: no root element found
Location: chrome://browser/content/webrtcIndicator.xhtml
Line Number 1, Column 1:

Hello,

It seems I meet the same issue since about 6 months, and had it on two different laptop (I change my laptop recently).

Computer 1 (not used since 1 month) :
Firefox 85.0.1 (64 bits)
Ubuntu 18.04.5 LTS
Linux 5.4.0-65-generic

Computer 2 (currently used):
Firefox 86.0 (64 bits)
Ubuntu 20.04.1 LTS
Linux 5.4.0-66-generic

Sometimes, when I join a video conference (google meet or others), access to audio trigger the error, but audio/video are working fine.
It is really hard to reproduce, since the issue appears randomly (I would say once every two weeks).
Closing all Firefox processes, or even a reboot does not solve the issue. It seems it disappears after working with the laptop for a day (having the issue all day)
and not using the laptop for the night. On the next morning, it will works fine again.
I don't have the issue with other browser when joining video conference (tested with chromium).

This window is very annoying as it stays always visible as long as I stay in the video conference, it also stays on top, that makes this part of the screen unusable ...

I can confirm that the issue is related to the WebRTC overlay indicator that is displayed while a video conference is ongoing (https://i.redd.it/zbpfi7vmjr201.png),
as the indicator is not displayed when having the issue and as the error is does not appear when privacy.webrtc.legacyGlobalIndicator is set to false in about:config.

Regards,

Jonathan.

Thanks for the detailed report! I'll try to reproduce this.

Severity: -- → S3
Flags: needinfo?(pbz)
Priority: -- → P3

This error is back on Firefox release 89.0 (64bit).

I am able to reproduce this by joining a Google Meetup video call. As soon as I stop that call, the error message goes away. It is exactly as describe previously in this thread.

I am experiencing this issue on MacOS Big Sur (11.3) and Firefix 89.0.2 (64bit). I have the issue with Google Meet and with Amazon Chime.

I'm experiencing on Firefox Beta 90.0b12 (64-bit) - Linux - on google meet. ( Started just today - Jul 2, 2021 ). My Browser wasn't updated since yesterday, perhaps something on google meet that invoked something extra/different ?

I closed my browser, waited... and restarted. The problem is gone ! No updates, still at the same - Firefox Beta 90.0b12 (64-bit) - Linux

I am experiencing this issue right now. Whenever I enable my microphone on google meet this window appears with this message.
It started after I upgraded my Firefox version to 89.0.2 (64-bits).

Flags: needinfo?(elbio.caetano)
Flags: needinfo?(pbz)
See Also: → 1703346

I also started to get this error on google meet and meet.jit.si
Starting in a private window, the error still show up, even with all add-on disabled
Starting the same firefox version with a clean profile, the error do not show up, so seems related to some stored config

Forgot to add that i'm on linux, as several reports already, like both mac and windows, so but platform should be updated to all

OS: Windows 10 → All
Hardware: x86_64 → Desktop
See Also: → 1749861
Status: REOPENED → NEW
status-firefox84: affected → wontfix
status-firefox98: --- → affected
status-firefox-esr91: --- → affected

Nightly, Gnome Xwayland, Debian Testing, Intel
I got this in Discord and was only sharing my microphone.

After some doing updates yesterday, I'm experiencing this problem too in Firefox on Linux.

Whenever I open Google Meet in Firefox and accept microphone permissions, the error window comes up and is fixed, covering everything in the desktop.

Ubuntu 21.10
Firefox 96.0.2

Summarizing workarounds (for other newbs like me):

  1. Resize your windows so you can keep working =(
  2. In Firefox, go to "about:config", search for "privacy.webrtc.legacyGlobalIndicator", set it to FALSE, reload the offending tab (e.g. Google Meet)

Problem also observed with:

  • Firefox 97.0
  • OSX Catalina (10.15.7)
  • When opening a Slack huddle

The error window closed itself when the Slack huddle was closed. Otherwise there was no way to close, move, minimize, or push to the back, the error window.

status-firefox97: --- → affected

I get the same issue with Google Meet, starting from today.

My environment is:

  • Firefox 91.5.0esr (64-bit)
  • RHEL 8.5

Hitting this bug myself just now in openSUSE with discord. Reversing the comment about "privacy.webrtc.legacyGlobalIndicator = true" and setting it to false avoids the behaviour, I expect this is bad, but it at least is a lot less annoying.

Could the dialog at least be always on top only for a few minutes? Or closable?

See Also: → 1714410

Can confirm this bug occurs on:

Firefox 98.0.1
Windows 10 (19043.1586)

Occurs randomly (random days, apparently consistently within a day) when joining a voice call in Discord web. There appears to be no way to hide/background the popup.

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates.
:pbz, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Flags: needinfo?(pbz)

The issue is not restricted to our test environments. Quite a lot of users are running into this after updating their browser. Bumping severity.
:hsinyi, could you help to find an assignee for this bug? Looking at the comment here it may be chrome window related: https://bugzilla.mozilla.org/show_bug.cgi?id=1703346#c65 Thanks!

Severity: S3 → S2
Flags: needinfo?(pbz) → needinfo?(htsai)

Randell, my goodbye emails from Zibi indicated you were the next person to look at YSODs. Notably, this one says "no root element found". Any idea what's up here?

Component: Site Permissions → Networking: JAR
Flags: needinfo?(rjesup)
Product: Firefox → Core

Not really. I have a patch that should land soon (need an r+ from extensions for a minor test tweak), bug 1744043. That might reduce instances of jar corruptions, which lead to YSOD (and perhaps this). This is an unproven hypothesis, based on the number of potential issues in JAR that might cause data corruptions in the file.

Flags: needinfo?(rjesup)

That bug is landing now, but given the randomness of this issue, we'll likely need to wait for it to go to release to be sure, or even past then.

(In reply to Paul Zühlcke [:pbz] from comment #33)

The issue is not restricted to our test environments. Quite a lot of users are running into this after updating their browser. Bumping severity.
:hsinyi, could you help to find an assignee for this bug? Looking at the comment here it may be chrome window related: https://bugzilla.mozilla.org/show_bug.cgi?id=1703346#c65 Thanks!

https://bugzilla.mozilla.org/show_bug.cgi?id=1739491#c4 mentioned that "All of them are preceeded by zero_byte_load from Necko with NS_BINDING_ABORTED." I am not sure if that is the same cause as what bug 1703346 comment 65 mentioned. Do you have ideas which cause(s) were the reports here about?

Flags: needinfo?(htsai) → needinfo?(pbz)

I'm not sure what the cause for these reports is. I was mainly looking to find somebody to own / investigate this. The comment you linked is probably more accurate for this issue though.
An interesting pattern is that the bug tends to occur after updating Firefox.

Thanks for finding a more appropriate bug component Gijs!

Flags: needinfo?(pbz)

JAR files are commonly changed during or on first (early?) runs after updates, so that makes sense if the locking issues in bug 1744043 were the cause of corruption. There also could be some logic error in the JAR code (or perhaps the code calling it) that could lead to corruption. A copy of a corrupted JAR file might give clues.

This happen to me recently on 98.0.2 version. Troubleshooting mode solve the issue, though.

Same issue on Google meet:

  • firefox: 99.0.1 (64bits) - french
  • Windows: 10 Pro 21H2

view-source:chrome://browser/content/webrtcIndicator.xhtml :

 1: <?xml version="1.0"?>
...
 6: <?xml-stylesheet href="chrome://global/skin/global.css" type="text/css"?>
 7: <?xml-stylesheet href="chrome://browser/skin/webRTC-indicator.css" type="text/css"?>
...
"Doctype isolated" (line underlined in red)
 9: <!DOCTYPE html>
10:
11: <html xmlns="http://www.w3.org/1999/xhtml"
12:       xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
13:       id="webrtcIndicator"
14:       windowtype="Browser:WebRTCGlobalIndicator"
15:       chromemargin="0,0,0,0">
16: 
...

Erreur d’analyse XML : aucun élément trouvé
Emplacement : chrome://browser/content/webrtcIndicator.xhtml
Numéro de ligne 1, Colonne 1 :

^
See Also: → 1763899

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #37)

(In reply to Paul Zühlcke [:pbz] from comment #33)

The issue is not restricted to our test environments. Quite a lot of users are running into this after updating their browser. Bumping severity.
:hsinyi, could you help to find an assignee for this bug? Looking at the comment here it may be chrome window related: https://bugzilla.mozilla.org/show_bug.cgi?id=1703346#c65 Thanks!

https://bugzilla.mozilla.org/show_bug.cgi?id=1739491#c4 mentioned that "All of them are preceeded by zero_byte_load from Necko with NS_BINDING_ABORTED." I am not sure if that is the same cause as what bug 1703346 comment 65 mentioned. Do you have ideas which cause(s) were the reports here about?

Just FYI, the error code NS_BINDING_ABORTED means that the request used to load the resource is cancelled by the consumer.
I think this is more related to how a Chrome window handles the case when a load is cancelled.
Hsin-Yi, could you check what Peter thinks about this? Since he didn't reply to the ni in bug 1703346. Thanks.

Flags: needinfo?(htsai)

Redirect needinfos that are pending on inactive users to the triage owner.
:dragana, since the bug has high severity and recent activity, could you have a look please?

For more information, please visit auto_nag documentation.

Flags: needinfo?(timothycoffelt)
Flags: needinfo?(nineohnine)
Flags: needinfo?(elbio.caetano)
Flags: needinfo?(dd.mozilla)
Flags: needinfo?(dd.mozilla)

I'm seeing this error almost daily on Gnome Wayland.

status-firefox101: --- → wontfix
status-firefox102: --- → affected
status-firefox103: --- → affected
status-firefox97: affected → wontfix
status-firefox98: affected → wontfix
status-firefox-esr102: --- → affected

Also happening to me every time I use something that requires microphone access. I'm on version 101.00 for Windows but this has been happening consistently for like 4 months.

See Also: → 1773504

(In reply to Darkspirit from comment #45)

I'm seeing this error almost daily on Gnome Wayland.

Is this on Nightly? And using snap builds, distro-provided or mozilla-provided? Once you hit this, can you create a copy of your profile folder, then open about:support, click the "clear startup cache" button, restart the browser, and check if that fixed the issue?

Flags: needinfo?(jan)

(In reply to Kershaw Chang [:kershaw] from comment #43)

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #37)

(In reply to Paul Zühlcke [:pbz] from comment #33)

The issue is not restricted to our test environments. Quite a lot of users are running into this after updating their browser. Bumping severity.
:hsinyi, could you help to find an assignee for this bug? Looking at the comment here it may be chrome window related: https://bugzilla.mozilla.org/show_bug.cgi?id=1703346#c65 Thanks!

https://bugzilla.mozilla.org/show_bug.cgi?id=1739491#c4 mentioned that "All of them are preceeded by zero_byte_load from Necko with NS_BINDING_ABORTED." I am not sure if that is the same cause as what bug 1703346 comment 65 mentioned. Do you have ideas which cause(s) were the reports here about?

Just FYI, the error code NS_BINDING_ABORTED means that the request used to load the resource is cancelled by the consumer.
I think this is more related to how a Chrome window handles the case when a load is cancelled.
Hsin-Yi, could you check what Peter thinks about this? Since he didn't reply to the ni in bug 1703346. Thanks.

There's another discussion thread in https://bugzilla.mozilla.org/show_bug.cgi?id=1773504

Flags: needinfo?(htsai)

(In reply to :Gijs (he/him) from comment #47)

(In reply to Darkspirit from comment #45)

I'm seeing this error almost daily on Gnome Wayland.

Is this on Nightly? And using snap builds, distro-provided or mozilla-provided? Once you hit this, can you create a copy of your profile folder, then open about:support, click the "clear startup cache" button, restart the browser, and check if that fixed the issue?

The original https://nightly.mozilla.org.
I haven't seen the bug in the last 2 days.

These 3 cache-related prefs are modified:

browser.cache.disk.enable false
browser.cache.disk_cache_ssl false
browser.startup.homepage.abouthome_cache.enabled false

The bug occured with Discord, the only WebRTC app I use. It's an app tab and I think the last time I saw this error was when restarting Nightly and automatically reconnecting to Discord.

Uncommon things I sometimes do:

  • Sometimes I use firefox/firefox -P otherprofile in parallel to my main profile.
  • Nightly has MOZ_ENABLE_WAYLAND=1 by default (bug 1543600). Last week (bug 1752494) I started Nightly with MOZ_ENABLE_WAYLAND=0 environment variable to test VAAPI with xwayland.

I'll keep the needinfo and wait for this bug to occur again.

Another "me too". Is there anything we can provide to help?

Happens on google meet. Started happening around the release of version 101.

Firefox 101.0.1 (64-bit)
Windows 10

It happened for me too while trying to join a Discord call.
Windows 10,
Firefox Nightly Version 104.0a1

However, on restarting, the notification went away.

Not sure if this has been mentioned, but the problem went away with the v102 update.

The icons are now showing in the tray when using a webrtc application (meet) with mic/webcam authorisations.

It feels like the issue was with some corrupted update?

This has started happening to me today, on every google meet that I join.

Just to add II appear to be unable to edit my previous comment) - I'm on 95.0 (64-bit) on Linux (Ubuntu) which may be a bit old. I will attempt to update (I think something python-related is screwing my updates).

Just realised I had a google meet today and the issue didn't occur, so presumably it was fixed by updating.

Hi! Another report, same here, this started to happen to me today with the latest manjaro release using gnome and latest firefox version.

I've hit this twice today once on google meet and also on grasshopper web app, both related to voip activity. Google meet I hit when opening sessions, same with Grasshopper but both with dialog for chose voice device. I did notice java dialog opened and it did make me think about jar files so maybe jar file is source of issue, not binding properly. I'd be happen to run a debug log if someone helps me.

I experience the same behaviour. It does not happen on chromium but does in firefox in both google meet calls and zoom calls after authorizing camera usage.

ArchLinux Zen Kernel 5.18.10 X11 KDE Plasma 5.25.3

(In reply to markballew from comment #57)

I've hit this twice today once on google meet and also on grasshopper web app, both related to voip activity. Google meet I hit when opening sessions, same with Grasshopper but both with dialog for chose voice device. I did notice java dialog opened and it did make me think about jar files so maybe jar file is source of issue, not binding properly. I'd be happen to run a debug log if someone helps me

It may be that the jar package needs to be identified and the mozilla team needs to reach out to Oracle Java team to help debug the binding.

(In reply to markballew from comment #59)

(In reply to markballew from comment #57)

I've hit this twice today once on google meet and also on grasshopper web app, both related to voip activity. Google meet I hit when opening sessions, same with Grasshopper but both with dialog for chose voice device. I did notice java dialog opened and it did make me think about jar files so maybe jar file is source of issue, not binding properly. I'd be happen to run a debug log if someone helps me

It may be that the jar package needs to be identified and the mozilla team needs to reach out to Oracle Java team to help debug the binding.

from inspect this is what happens at time error is thrown, but I don't get any error in inspect console, just this warning.
navigator.mozGetUserMedia has been replaced by navigator.mediaDevices.getUserMedia

(In reply to markballew from comment #59)

It may be that the jar package needs to be identified and the mozilla team needs to reach out to Oracle Java team to help debug the binding.

Despite sharing the name, the jar name/extension in this case is not actually related to java or Oracle. It's basically just an uncompressed zip archive - we don't actually use java as part of desktop Firefox. The history of the confusing naming is long and tedious and probably not super relevant here.

In terms of helping us debug, the simplest thing to check would be if it still happens after restarting Firefox, and if so, if you make a copy of your profile folder, and then go to about:support, click the "Clear startup cache..." button on the top right, and then restart Firefox, and see if it still happens?

Jesup, looks like we're not out of the woods here still. Any idea how we could get further information here beyond what I just suggested?

Flags: needinfo?(rjesup)
Flags: needinfo?(markballew)

Windows 10 21H2
Firefox 102.0.1 (64 bits)

Restarted Firefox after a computer crash, was hit by the same issue when connecting to a Discord vocal channel. Restarting the computer, thus Firefox, fixed it.

At this point, it seems clear this is a one-time issue that happens after an update, almost certainly related in some manner to the startup cache. I've hit it myself, but unfortunately at a time I couldn't stop and investigate; as usual quitting and restarting the browser fixed it. We did get some detailed info from emilio when he hit it (until he crashed the browser and the problem went away). It almost seemed like it was the in-memory copy of the startup cache that was the issue.

Serious vetting or some more complete testing of the startup cache might reveal the problem.

Flags: needinfo?(rjesup)

At this point, it seems clear this is a one-time issue that happens after an update

This is incomplete. I think we see at least two scenarios:

  • One time issue
  • Repetitive issue

It seems like some of the investigators keep repeating the assumption that only the former exists.

I can confirm that I was hit by the latter and was able to restart the OS and restart the browser and kept seeing the same error until I updated the browser.

It almost seemed like it was the in-memory copy of the startup cache that was the issue.

This has been my hypothesis for a bit now. I think there's some cache that gets cached even when I/O is broken. So if I/O loads a zero-length file, cache caches it, then the next request loads it from cache as zero-length until update invalidates the cache.

I suspect that the fix will be to stop caching if the fetch is zero-length.

I also want to point out that telemetry shows another scenario, where instead of zero-length we get a mangled bytes. So instead of fetching index.html as <html>\n\n<head> ... we fetch it as <html>\n\n<hedshfdjwefnwerjnvkj43wlkqdf.d.dfdwdfkm2332emrd$R@NJKnfdfd. - very long broken byte string.
Recognizing and avoiding caching that is going to be more tricky, but from what I remember the ratio of zero-length to mangled was at least 10:1 so just identifying zero-length should help a lot.

I got this error message with the latest update of firefox developer edition (104.0b8 (64-bit)) on macos Monterey on Apple m1 device.
It wasn't exist before this update.
I've checked it on many different websites including:
https://webrtc.github.io/samples/src/content/getusermedia/gum/
https://test.8x8.vc/

The update to 104.0.1 (64-bit) broke is again for me after a few versions of respite.
It seems that the auto-updating process has the tendency to trigger this bug.

I've tried installing Firefox using the latest installer (without un-installing it, just forcing an update) without success.

(In reply to Geoffrey D. from comment #66)

The update to 104.0.1 (64-bit) broke is again for me after a few versions of respite.
It seems that the auto-updating process has the tendency to trigger this bug.

I've tried installing Firefox using the latest installer (without un-installing it, just forcing an update) without success.

I can confirm my issue is definitely with the startup cache.

The work around is as follow:
1- Open an about:support tab
2- Click the "Clear startup cache..." button and restart

This completely fixed it for me.

Thank you for confirming. I'm going to move this to startup-cache then.
Even if this bug is somehow related to JAR code, I think we need a way to reliably trigger the bug.

Component: Networking: JAR → Startup and Profile System
Product: Core → Toolkit
See Also: → 1667772

I'm also having this problem, it happens when I use wayland. I'm in fedora 37.

Hi, can you reliably reproduce this? If so, would you be available to do a zoom call and help me debug this? Thanks!

Flags: needinfo?(mazzasantino1206)

(In reply to Valentin Gosu [:valentin] (he/him) from comment #70)

Hi, can you reliably reproduce this? If so, would you be available to do a zoom call and help me debug this? Thanks!

Hello, yes I can help you! I forgot to point out that I was using firefox 105 because fedora 37 didn't receive firefox 106 yet, so first I want to try with firefox 106 to make sure it hasn't been fixed yet.

Flags: needinfo?(mazzasantino1206)

Apparently when I rebooted fedora it started to work again, without updating.

:( Please let us know if it starts happening again.

FYI: you can close the always-on-top error window with Windows' close window short-cut Alt+F4.
in doing so, the window does pop-up again when switching focus back to Firefox, but only after a certain interval.
(Firefox 106.0.2, Windows 7!)

If you can reproduce this consistently, we'd appreciate some help in diagnosing the issue.

Flags: needinfo?(thechange)

I can reproduce this on a machine in my family (Firefox 98.0 / Linux Mint 19.3) when logging into Skype. Other machines are not affected.
Is there anything you would like to know that I can contribute to this issue or the triaging ?
Kind regards,
Stefan

(In reply to Valentin Gosu [:valentin] (he/him) from comment #75)

If you can reproduce this consistently, we'd appreciate some help in diagnosing the issue.

it is very consistent, as apparent from also many other user reports
there's some more related information here, if it is not already known on bugzilla:

and this appears to be related to (or stem from) bug entry 1675823, which i didn't find a mention of, other than "YSOD", in the thread above

Hi, I just created an account here so I could report this: I was able to get the box to disappear by changing the value of privacy.webrtc.legacyGlobalIndicator to false in about:config. I'm not sure if this disables all sharing indicators, but at the very least it suppresses giant yellow error window.

Just started experiencing this issue pretty much exactly as described above in Firefox 107.0.1 (64-bit) on packaged for linux mint mint-001 - 1.0. It's a little odd that it's looking for chrome:// ? It only started happening after I upgraded firefox last week.

I upgrade via the mint upgrade manager, and this does look like it's the most recent version of Firefox.

This is happening on discord and on jitsi for me (presumably any platform that uses web rtc?)

I'm on mint 20.3

If this is reproducible, it would be very helpful if you could use https://rr-project.org/ to run firefox.
If the dialog shows up while running in rr, it will be much much easier to diagnose. Thank you!

Flags: needinfo?(svansintjan)
Flags: needinfo?(stefan.thieme)

obviously this is now no longer popping up, I'm trying to remember if I restarted my computer or not in the mean time, but I have installed rr for if I see it again.

Flags: needinfo?(svansintjan)

Hi. This bug is still reproducible, we have our own app using WebRTC and as soon as I allow to use camera or mic, the error is shown. This started to happen this morning, it was ok last week (last year to be precise). No changes in our code. I'm running FF 108.0.2 (64-bit) on OS X Ventura 13.1

Not reproducible after OS restart

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

For more information, please visit auto_nag documentation.

Flags: needinfo?(markballew) → needinfo?(dtownsend)
Component: Startup and Profile System → WebRTC
Flags: needinfo?(dtownsend)
Product: Toolkit → Core

Stared happening to me too on 109.0.1 (Windows)
Enabling privacy.webrtc.legacyGlobalIndicator solved the issue

Also present in 110.0.1+build2-0ubuntu0.22.04.1~mt1.

Whats worse is that its above "on top" windows, and it can't be moved, resized, or minimized.

If I go to about:config and set:

privacy.webrtc.legacyGlobalIndicator = false

This doesn't pop up for me anymore

I can confirm the behaviour from Coenraad. It was also present on firefox-bin-110.0.1 in Gentoo.
Changing privacy.webrtc.legacyGlobalIndicator = false stops this weired popup from showing.

(In reply to oz.tiram from comment #89)

I can confirm the behaviour from Coenraad. It was also present on firefox-bin-110.0.1 in Gentoo.
Changing privacy.webrtc.legacyGlobalIndicator = false stops this weired popup from showing.

As noted in the earlier comment from Valentin:

(In reply to Valentin Gosu [:valentin] (he/him) from comment #80)

If this is reproducible, it would be very helpful if you could use https://rr-project.org/ to run firefox.
If the dialog shows up while running in rr, it will be much much easier to diagnose. Thank you!

At the moment, because this issue is not reproducible for engineers, it's very difficult for us to diagnose and fix. The file about which it is complaining does exist and has a root element (unlike what the error suggests), so something is going wrong in trying to read it, but it's unclear what, exactly. The preference people flip just switches to a different file (and different way of showing webrtc activity) - it doesn't really "fix" anything - and of course it shouldn't be needed to change any preferences to avoid having this strange error show up, so we'd really like to get to the bottom of it.

Flags: needinfo?(oz.tiram)
Flags: needinfo?(coenraad)

When I get the XML parsing error this other error appears on the browser console:

 error in gIndicatorWindow.updateIndicatorState(): gIndicatorWindow.updateIndicatorState is not a function webrtcUI.jsm:894:19
    updateGlobalIndicator resource:///modules/webrtcUI.jsm:894
    updateIndicators resource:///modules/webrtcUI.jsm:733
    updateIndicators resource:///actors/WebRTCParent.jsm:159
    receiveMessage resource:///actors/WebRTCParent.jsm:151

I am a Kali user and it happens on the Firefox version[102.6.0esr (64-bit)]. I join the Discord voice channel and this popup interface came.

Flags: needinfo?(lutherdream25)

This happening as well in 112.0.1 (64-bit) on Windows 11. I am willing & able to take debugging steps in aid of solving this issue.

(In reply to u726354 from comment #93)

This happening as well in 112.0.1 (64-bit) on Windows 11. I am willing & able to take debugging steps in aid of solving this issue.

I can attest similar issue & can also aid in resolving.

We're pretty convinced this is unrelated to webrtc corer logic. Necko, dom or site permissions related probably.

No longer blocks: webrtc-triage
Component: WebRTC → Site Permissions
Flags: needinfo?(thechange)
Flags: needinfo?(stefan.thieme)
Flags: needinfo?(oz.tiram)
Flags: needinfo?(lutherdream25)
Flags: needinfo?(jan)
Flags: needinfo?(coenraad)
Product: Core → Firefox

This happens to other things than webrtc and I think that's been clear for a while (e.g. bug 1763899). Whether it's DOM/necko/startupcache/zipreadercache stuff getting things wrong... that's what's unclear, and without steps to reproduce or more details from people seeing this, it's difficult to do much here.

Component: Site Permissions → Networking
Product: Firefox → Core
Depends on: 1696551
Whiteboard: [necko-triaged]

This strongly appears to be caused by using an "old" startup cache, since we've pretty much proven with Emilio that we were using the previous version's data on the first run that should be using new data. This would exactly match the symptoms of not clearing the startup cache on the first run after an update/upgrade, since with emilio we found that the omnijar did in fact have the correct data. Thus far I haven't been able to figure out a mechanism that would cause this.

Assignee: nobody → rjesup
Component: Networking → XPCOM

FWIW, this was a successful workaround/fix for me:

(In reply to :Gijs (he/him) from comment #47)

open about:support, click the "clear startup cache" button, restart the browser

In case it's useful, I think this may be related to the fact that I re-installed my operating system onto a new disk, and migrated my home directory from the old one. I'm not quite sure the timing of when this showed up versus when I did that, but I know it used to not be a problem, and then sometime more recently it was. It's possible there were other more recent updates, though, too. Anyway, "clear startup cache" from about:support did the trick for me as a remedy.

Duplicate of this bug: 1850413
See Also: 1749861 →

Recently experienced this on 119.0 in Fedora 38.

Jesup, this is an S2 and you are the assignee. Are you still working on this?

Flags: needinfo?(rjesup)
Version: 77 Branch → unspecified

Isn't this essentially the same as Bug 1675823 - [meta] Yellow Screen of Death? Zibi landed a ton of telemetry to try and diagnose these issues. Unfortunately he has since left Moz.

Yes. This is one of the common results of the YSOD failure. See #ysod on matrix. The current belief is that this has something to do with the startupcache, IIRC
This is still getting looked at intermittedly. The problem is absolutely still ongoing

Flags: needinfo?(rjesup)

I'm currently on Firefox 122.0b3 (developer edition) and I am seing the same problem. It's just a bit worse for me though because Wayland (I'm on Ubuntu 22.04 LTS + KDE 5.24.7) doesn't allow for window positioning by the programs, so the window appears in the middle of my screen.
Luckily I can close the indicator window without destroying functionality.

I'm on Firefox 121.0 on macOS. I have the same issue and it video call using Firefox (meet, teams, ...) are impossible to do as I have a big yellow window on top. I'm on MacOS.

It started happening when I allowed firefox to share screen.

I also see the error window, as in the attached screenshot, on macOS 121.0.1 (64-bit) on a MacBook Air M1. I cannot remember to have done something special. The same installtion worked fine and unchanged for over a year. https://bugzilla.mozilla.org/attachment.cgi?id=9150703

Severity: S2 → S3

Same problem on Firefox 122.0.1 on KDE Neon 5.27.

Same problem on Firefox 122.0.1 on Ubuntu MATE 22.04, after updating yesterday. Prior to that it's been fine for many years, including on 122.0.

Started happening for me, too. Tested on discord.com and https://webrtc.github.io/test-pages/src/audio-and-video/, happens on both.

Firefox 122.0.1, build 20240205133611
MacOS 13.6.4

Extensions:
CanvasBlocker extension 1.9 true CanvasBlocker@kkapsner.de
Consent-O-Matic extension 1.0.12 true gdpr@cavi.au.dk
Decentraleyes extension 2.0.18 true jid1-BoFifL9Vbdl2zQ@jetpack
Disable WebRTC extension 1.0.23 true jid1-5Fs7iTLscUaZBgwr@jetpack
Don't track me Google extension 4.28 true dont-track-me-google@robwu.nl
Firefox Multi-Account Containers extension 8.1.3 true @testpilot-containers
GNOME Shell integration extension 11.1 true chrome-gnome-shell@gnome.org
KeePassXC-Browser extension 1.8.12 true keepassxc-browser@keepassxc.org
NoScript extension 11.4.29 true {73a6fe31-595d-460b-a920-fcc0f8843232}
OctoLinker extension 6.10.5 true octolinker@stefanbuck.com
Select After Closing Current extension 5.3 true select-after-closing-current@qw.linux-2g64.local
Tree Style Tab extension 3.9.22 true treestyletab@piro.sakura.ne.jp
uBlock Origin extension 1.55.0 true uBlock0@raymondhill.net

See Also: → 1880166

If anyone is still seeing this, it would be helpful if you could go to about:telemetry, search for ysod and share what you're seeing there (screenshot, or copy-paste the table data, if it's not empty).

If the previous time you saw this was on a previous time you ran Firefox, or on a different day, you may need to use the arrow next to "current data" on the top left of the page, and switch to data from an archived ping corresponding to the time when you saw the yellow error screen.

So far, for most people, the problem has gone away after restarting the browser. If this is not the case for you, we would also really like to know.

The telemetry data related to ysod

1565995 ysod shown ysod chrome://browser/content/webrtcIndicator.xhtml {"error_code": "3", "location": "1:1", "last_line": "", "last_line_len": "0", "hidden": "true", "destroyed": "true"}

I get no search results searching for ysod in about:telemetry. I've already restarted firefox multiple times since then, still persistently get the broken window with the webrtcIndicator error message.

(In reply to francis from comment #111)

The telemetry data related to ysod

1565995 ysod shown ysod chrome://browser/content/webrtcIndicator.xhtml {"error_code": "3", "location": "1:1", "last_line": "", "last_line_len": "0", "hidden": "true", "destroyed": "true"}

Thanks! Are you still seeing the broken screen, or has it gone away? If you're still seeing it, does it appearing once or twice more cause more of these lines to show up when you search telemetry again (you'll want to refresh the about:telemetry page before checking)

(In reply to a.geek.dude+mozbugz from comment #112)

I get no search results searching for ysod in about:telemetry. I've already restarted firefox multiple times since then, still persistently get the broken window with the webrtcIndicator error message.

Thanks for the update. If you go to about:support (Help > More Troubleshooting Information), and click "Clear startup cache..." (will cause a restart), does the issue go away?

Flags: needinfo?(francis)
Flags: needinfo?(a.geek.dude+mozbugz)

(In reply to :Gijs (he/him) from comment #113)

(In reply to a.geek.dude+mozbugz from comment #112)

I get no search results searching for ysod in about:telemetry. I've already restarted firefox multiple times since then, still persistently get the broken window with the webrtcIndicator error message.

Thanks for the update. If you go to about:support (Help > More Troubleshooting Information), and click "Clear startup cache..." (will cause a restart), does the issue go away?

It's gone after clearing the startup cache.

Flags: needinfo?(a.geek.dude+mozbugz)

(In reply to a.geek.dude+mozbugz from comment #114)

It's gone after clearing the startup cache.

Thanks for confirming. I would expect the patch in bug 1880262 (likely to land in Firefox 124, which will be in beta next week) to fix this going forward.

This is happening when using Google meet - this is consistent and started I believe today . . The popup comes, meet operates normally. By restarting the popup obviously disappears.

Flags: needinfo?(francis)

(In reply to francis from comment #116)

This is happening when using Google meet - this is consistent and started I believe today . . The popup comes, meet operates normally. By restarting the popup obviously disappears.

Same here.

(In reply to a.geek.dude+mozbugz from comment #114)

(In reply to :Gijs (he/him) from comment #113)

Thanks for the update. If you go to about:support (Help > More Troubleshooting Information), and click "Clear startup cache..." (will cause a restart), does the issue go away?

It's gone after clearing the startup cache.

Here is the workaround, for the time being.

Whiteboard: [necko-triaged] → [necko-triaged][workaround in comment 118]

(In reply to a.geek.dude+mozbugz from comment #118)

(In reply to a.geek.dude+mozbugz from comment #114)

(In reply to :Gijs (he/him) from comment #113)

Thanks for the update. If you go to about:support (Help > More Troubleshooting Information), and click "Clear startup cache..." (will cause a restart), does the issue go away?

It's gone after clearing the startup cache.

Here is the workaround, for the time being.

Thanks, works!

As of today this suddenly happens for me when opening meet.google.com. I did not update Firefox today.
Firefox 123.0.1.

XML Parsing Error: no root element found
Location: chrome://browser/content/webrtcIndicator.xhtml
Line Number 1, Column 1:

(In reply to Sven from comment #120)

As of today this suddenly happens for me when opening meet.google.com. I did not update Firefox today.

Is it possible that you updated a bit earlier (the day or week before) and that you didn't use google meet or a similar web video/audio calling service since updating, until you hit this problem?

Firefox 123.0.1.

We're hoping this is fixed in 124 (to be released in about 2 weeks) but for now as a workaround, if you open about:support and then click the "clear startup cache" button, and restart the browser, the problem should be gone. Let us know if that works?

Flags: needinfo?(mail)

Is it possible that you updated a bit earlier (the day or week before) and that you didn't use google meet or a similar web video/audio calling service since updating, until you hit this problem?

I updated yesterday but I use Meet multiple times a day.
But I'm not 100% if I used Meet after I updated FF yesterday.

We're hoping this is fixed in 124 (to be released in about 2 weeks) but for now as a workaround, if you open about:support and then click the "clear startup cache" button, and restart the browser, the problem should be gone. Let us know if that works?

Yes, that helped! Thanks!

Flags: needinfo?(mail)

I have been getting this bug for a few days with latest firefox on Manjaro. I have not restarted browser yet, but this bug started for me when I tried to drag a google meet tab out of the main window and into its own window. Now whenever there is a webrtc in a web page, I get this error and it displays on top of all my windows.

(In reply to sam from comment #124)

I have been getting this bug for a few days with latest firefox on Manjaro. I have not restarted browser yet, but this bug started for me when I tried to drag a google meet tab out of the main window and into its own window. Now whenever there is a webrtc in a web page, I get this error and it displays on top of all my windows.

What version of Firefox are you using? (Help > About Firefox can tell you if you're unsure)

Flags: needinfo?(sam)

(In reply to :Gijs (he/him) from comment #125)

(In reply to sam from comment #124)

I have been getting this bug for a few days with latest firefox on Manjaro. I have not restarted browser yet, but this bug started for me when I tried to drag a google meet tab out of the main window and into its own window. Now whenever there is a webrtc in a web page, I get this error and it displays on top of all my windows.

What version of Firefox are you using? (Help > About Firefox can tell you if you're unsure)
About Firefox:

Firefox 123 (64-bit)
Mozilla Firefox for Manjaro Linux
Manjaro - 1.0

neofetch:

OS: Manjaro Linux x86_64 
Host: Alienware Aurora R15 
Kernel: 6.1.80-1-MANJARO 
Uptime: 9 days, 16 hours, 35 mins 
Packages: 1428 (pacman), 1 (brew), 10 (flatpak) 
Shell: zsh 5.9 
Resolution: 4880x3440 
DE: Plasma 5.27.10 
WM: KWin 
Theme: [Plasma], Breeze [GTK2/3] 
Icons: breeze-dark [Plasma], breeze-dark [GTK2/3] 
Terminal: vscode 
CPU: 13th Gen Intel i9-13900KF (32) @ 6.000GHz 
GPU: NVIDIA GeForce RTX 4090 
Memory: 35929MiB / 64018MiB
Flags: needinfo?(sam)

(In reply to sam from comment #126)

(In reply to :Gijs (he/him) from comment #125)

(In reply to sam from comment #124)

I have been getting this bug for a few days with latest firefox on Manjaro. I have not restarted browser yet, but this bug started for me when I tried to drag a google meet tab out of the main window and into its own window. Now whenever there is a webrtc in a web page, I get this error and it displays on top of all my windows.

What version of Firefox are you using? (Help > About Firefox can tell you if you're unsure)
About Firefox:

Firefox 123 (64-bit)
Mozilla Firefox for Manjaro Linux
Manjaro - 1.0

Thanks. There's a fix riding with 124.

If you've still not restarted and/or are still seeing the issue, then one thing that may be interesting is if you copy the startupCache.8.little file from your profile's "local" directory (should be somewhere under either XDG_CACHE_HOME or ~/.cache on Linux, in a mozilla or firefox-y subdir, with the same individual directory name as your profile that is linked from about:support). Then compare the "broken" copy with what shows up in the same file after using the instructions in comment #122 (which will wipe the files) and using meet or another webrtc-y page at least once, such that the indicator appears. Particularly the bytes following any mention of webrtcIndicator.xhtml. I expect that they're different in the good vs. bad case but it would be good to confirm.

124 is out today, so as soon as you update to it that will wipe that cache file anyway. If the problem reoccurs once you're on 124 that would be interesting to know (but even if the fix is not effective, it would be somewhat surprising if you were seeing it again quickly post-update, due to the fact that the cache file gets wiped after any/every app version change).

(In reply to :Gijs (he/him) from comment #127)

(In reply to sam from comment #126)

(In reply to :Gijs (he/him) from comment #125)

(In reply to sam from comment #124)

I have been getting this bug for a few days with latest firefox on Manjaro. I have not restarted browser yet, but this bug started for me when I tried to drag a google meet tab out of the main window and into its own window. Now whenever there is a webrtc in a web page, I get this error and it displays on top of all my windows.

What version of Firefox are you using? (Help > About Firefox can tell you if you're unsure)
About Firefox:

Firefox 123 (64-bit)
Mozilla Firefox for Manjaro Linux
Manjaro - 1.0

Thanks. There's a fix riding with 124.

If you've still not restarted and/or are still seeing the issue, then one thing that may be interesting is if you copy the startupCache.8.little file from your profile's "local" directory (should be somewhere under either XDG_CACHE_HOME or ~/.cache on Linux, in a mozilla or firefox-y subdir, with the same individual directory name as your profile that is linked from about:support). Then compare the "broken" copy with what shows up in the same file after using the instructions in comment #122 (which will wipe the files) and using meet or another webrtc-y page at least once, such that the indicator appears. Particularly the bytes following any mention of webrtcIndicator.xhtml. I expect that they're different in the good vs. bad case but it would be good to confirm.

124 is out today, so as soon as you update to it that will wipe that cache file anyway. If the problem reoccurs once you're on 124 that would be interesting to know (but even if the fix is not effective, it would be somewhat surprising if you were seeing it again quickly post-update, due to the fact that the cache file gets wiped after any/every app version change).

awesome, I found the folder but not sure which file you are interested in?

➜  firefox tree -L 3
.
├── 3zfxzxmv.default
└── 6alv1myc.default-release
    ├── activity-stream.discovery_stream.json
    ├── activity-stream.personalization.json
    ├── cache2
    │   ├── doomed
    │   ├── entries
    │   └── index
    ├── personality-provider
    │   ├── nb_model_build_attachment_arts_and_entertainment.json
    │   ├── nb_model_build_attachment_autos_and_vehicles.json
    │   ├── nb_model_build_attachment_beauty_and_fitness.json
    │   ├── nb_model_build_attachment_blogging_resources_and_services.json
    │   ├── nb_model_build_attachment_books_and_literature.json
    │   ├── nb_model_build_attachment_business_and_industrial.json
    │   ├── nb_model_build_attachment_computers_and_electronics.json
    │   ├── nb_model_build_attachment_finance.json
    │   ├── nb_model_build_attachment_food_and_drink.json
    │   ├── nb_model_build_attachment_games.json
    │   ├── nb_model_build_attachment_health.json
    │   ├── nb_model_build_attachment_hobbies_and_leisure.json
    │   ├── nb_model_build_attachment_home_and_garden.json
    │   ├── nb_model_build_attachment_internet_and_telecom.json
    │   ├── nb_model_build_attachment_jobs_and_education.json
    │   ├── nb_model_build_attachment_law_and_government.json
    │   ├── nb_model_build_attachment_online_communities.json
    │   ├── nb_model_build_attachment_people_and_society.json
    │   ├── nb_model_build_attachment_pets_and_animals.json
    │   ├── nb_model_build_attachment_real_estate.json
    │   ├── nb_model_build_attachment_reference.json
    │   ├── nb_model_build_attachment_science.json
    │   ├── nb_model_build_attachment_shopping.json
    │   ├── nb_model_build_attachment_sports.json
    │   ├── nb_model_build_attachment_travel.json
    │   └── recipe_attachment.json
    ├── safebrowsing
    │   ├── ads-track-digest256.sbstore
    │   ├── ads-track-digest256.vlpset
    │   ├── analytics-track-digest256.sbstore
    │   ├── analytics-track-digest256.vlpset
    │   ├── base-cryptomining-track-digest256.sbstore
    │   ├── base-cryptomining-track-digest256.vlpset
    │   ├── base-email-track-digest256.sbstore
    │   ├── base-email-track-digest256.vlpset
    │   ├── base-fingerprinting-track-digest256.sbstore
    │   ├── base-fingerprinting-track-digest256.vlpset
    │   ├── content-email-track-digest256.sbstore
    │   ├── content-email-track-digest256.vlpset
    │   ├── content-track-digest256.sbstore
    │   ├── content-track-digest256.vlpset
    │   ├── google4
    │   ├── google-trackwhite-digest256.sbstore
    │   ├── google-trackwhite-digest256.vlpset
    │   ├── mozplugin-block-digest256.sbstore
    │   ├── mozplugin-block-digest256.vlpset
    │   ├── mozstd-trackwhite-digest256.sbstore
    │   ├── mozstd-trackwhite-digest256.vlpset
    │   ├── social-track-digest256.sbstore
    │   ├── social-track-digest256.vlpset
    │   ├── social-tracking-protection-facebook-digest256.sbstore
    │   ├── social-tracking-protection-facebook-digest256.vlpset
    │   ├── social-tracking-protection-linkedin-digest256.sbstore
    │   ├── social-tracking-protection-linkedin-digest256.vlpset
    │   ├── social-tracking-protection-twitter-digest256.sbstore
    │   └── social-tracking-protection-twitter-digest256.vlpset
    ├── settings
    │   └── main
    ├── startupCache
    │   ├── scriptCache-child-current.bin
    │   ├── scriptCache-current.bin
    │   ├── startupCache.8.little
    │   ├── urlCache.bin
    │   ├── urlCache-current.bin
    │   └── webext.sc.lz4
    └── thumbnails
        ├── ..........

(In reply to sam from comment #128)

awesome, I found the folder but not sure which file you are interested in?

➜  firefox tree -L 3
.
├── 3zfxzxmv.default
└── 6alv1myc.default-release
    ├── startupCache
    │   ├── startupCache.8.little

This one - startupCache/startupCache.8.little, assuming that default-release is definitely the profile you're running / seeing the issue on. So yeah, if you make a backup copy of it before wiping the cache per comment #122 + restarting, then open a webrtc thing, then compare the content around webrtcIndicator.xhtml in the new copy of the file, I'd expect to see some differences... if you feel comfortable, you can email the two files to me if you like (there shouldn't be anything personal in them, they're basically re-serializations of the DOM + JS files that ship with Firefox, done in such a way that they can be re-interpreted by a machine more quickly than the original HTML/JS can be parsed).

Depends on: 1880262
See Also: 1880166 →
status-firefox124: --- → ?

There haven't been any more comments in this bug for all of the 124 release cycle. 125 was released last week (we had some hiccups so we're on 125.0.2 now, I think). The absence of evidence is something of a poor proxy, but I suspect this means that we were successful in fixing this in bug 1880262.^^ I'm going to tentatively resolve this as worksforme on that basis.

Obviously we can reopen if people are still seeing this with up-to-date Firefox instances.

^^ "But surely Mozilla can tell with Telemetry whether or not this is fixed?" -- well, we wish - but the telemetry we have registers when the XML parser gets into this broken state for internal pages like the webrtc indicator. Except the brokenness we fixed (which we think is what is causing this bug for people) happens in an XML parser instance that never makes it to the screen because it gets aborted mid-parse - and the problem was that gecko was then caching that result and re-showing it to folks (which did make it to the screen). For which we don't have telemetry. We fixed both (a) caching the broken result and (b) using the broken result from cache if present, but neither of those go through the XML parser so neither generates telemetry that would then show a precipitous drop in instances of this bug occurring. bug 1880317 covers improving the telemetry but we chose to land a fix first and worry about improving the data bits later. Which means we're "flying blind" to some degree.

Status: NEW → RESOLVED
Closed: 4 years ago → 17 hours ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: