Open Bug 1834526 Opened 11 months ago Updated 3 months ago

Large fetch in Web Worker in extension causes hang in Firefox extension process

Categories

(Core :: JavaScript: GC, defect, P2)

Product:
Core
Component:
JavaScript: GC
Type:
defect

Tracking

()

Project Flags:
Performance Impact low
Tracking Flags:
Tracking Status
firefox-esr102 --- unaffected
firefox113 --- wontfix
firefox114 --- wontfix
firefox115 --- wontfix
firefox116 --- wontfix

People

(Reporter: tdulcet, Unassigned, NeedInfo)

References

Details

(4 keywords)

Attachments

(3 files)

memory-report.json.gz
729.32 KB, application/x-gzip
Details
image.png
42.67 KB, image/png
Details
Leak of the response text even when it shouldn't be retained
1.03 KB, text/html
Details

I do not have a specific STR, but I have had this issue occur multiple times since the Firefox 113 update, so I thought I should report it. I have noticed that the CPU usage for the extension process periodically gets stuck at 100%, which can be seen from about:processes. This issue causes degraded browser performance and some functionality to quit working.

When this happens, the about:performance page flashes between showing only a small subset of my open tabs and none of my extensions, to showing everything as expected. When it does show the extensions, it attributes the high CPU usage to a random extension, but disabling that extension does not resolve the issue, as it then just attributes the issue to a different random extension.

The issue seems to occur shortly after a large fetch (of around 100 MiB) is started in a Web Worker in my Server Status extension, but this only happens around 50% of the time and only when fetching the data over the network (not from the browser cache). There are no errors in the extension console (using the workaround from bug 1777948 comment 2). I tried opening the browser console to see if there were any errors there, but it just opens as a blank window. The extension debugger also does not load, so I am unable to see what line in the Web Worker it is stopped on or further debug it, but the fetch does not seem to complete. Normally, it should take less than a minute. Disabling and reenabling this extension does temporally resolve the issue. The CPU usage returns to normal and the browser starts to work as expected again. However, the issue can occur again the next time Firefox is opened.

The code is this Web Worker is somewhat CPU intensive, as it processes two large CSV files. However, it only runs at most once per day and briefly for less than a minute each time. The extension has no unbounded loops that could account for this hang. In addition, the point of using a Web Worker is of course not to cause performance issues on the main thread, so even if the extension did somehow have a bug, this obviously should not cause indefinite 100% CPU usage in Firefox's extension process and it should not break any of Firefox's functionality. I will record a profile of the issue the next time it occurs and attach it to this bug.

The issue only occurs for me in Firefox 113. There are no issues in Firefox 102 ESR or any previous version of Firefox. Firefox Nightly is broken on my system (bug 1809415), so unfortunately I cannot test it on that. Another user of my extension did report having the issue in Firefox 114 Developer Edition.

I will record a profile of the issue the next time it occurs and attach it to this bug.

As promised, here is a profile of the issue: https://share.firefox.dev/43pkg27

I also created a much longer profile that is over 6 minutes, but it was too large to upload. I would be happy to share that by other means if needed.

Keywords: regression

This bug has been marked as a regression. Setting status flag for Nightly to affected.

status-firefox115: --- → affected

Julien, is this bug reported in the right component according to the profile provided? Thanks

Flags: needinfo?(felash)

All I can say from the profile, is that this DOM Worker from "Server Status" is very busy doing GC work. So I'd suspect a leak happening in the worker.

We might be able to know more with the longer profile. If you can push it somewhere so that I can download it, that would be very good.

Also these pieces of information could be useful:

  • 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.

Finally another way to look at it would be to use Firefox Nightly with the "Native Allocations" feature turned on (in about:profiling). Ideally you would profile this before anything goes wrong, doing some things that trigger work in Server Status, and this could give some indications about where memory is allocated and retained.

Thanks!

Performance Impact: --- → ?
Flags: needinfo?(felash)

(In reply to Julien Wajsberg [:julienw] from comment #5)

We might be able to know more with the longer profile. If you can push it somewhere so that I can download it, that would be very good.

Here is a link to the much longer profile: https://drive.google.com/uc?export=download&id=1ozrPVeKLnWIYAIkSmHZYVKM2C6aPCgjD

  • For memory usage issues, capture a memory dump from about:memory and attach it to this bug.

There does not appear to be any memory usage issues. The hang seems to last indefinitely, but the memory usage does not increase. However, I am happy to perform this step the next time the issue occurs. It looks like it actually occurs around 33% of the time instead of 50%.

Finally another way to look at it would be to use Firefox Nightly with the "Native Allocations" feature turned on (in about:profiling). Ideally you would profile this before anything goes wrong, doing some things that trigger work in Server Status, and this could give some indications about where memory is allocated and retained.

For some more information, my "Server Status" add-on downloads two somewhat large IP geolocation databases, one each for IPv4 and IPv6 respectively. The databases are in CSV format, so my add-on has to parse those files and convert them into a compact 2D array, which is stored in memory in the Web Worker. The code that does this is these 28 lines here, which is where it seems to be getting stuck. As you can see, there are no unbounded loops that could account for this hang, just a series of .map() calls. That switch statement is because there are currently 9 different databases supported, which are in a total of 3 unique formats (some of the databases have the full location, while others just the country). This code is run immediately after the add-on is installed, after Firefox is opened and by default once per day. After Firefox is opened when the add-on is loading, it explicitly set the cache option to the fetch() function to force-cache and the issue not occurred at this time, so it seems it only happens when an actual network request is made.

Anyway, simply installing my "Server Status" add-on in a fresh Firefox Nightly installation should generate a profile of what is supposed to happen, if that is what you are requesting.

Anyway, simply installing my "Server Status" add-on in a fresh Firefox Nightly installation should generate a profile of what is supposed to happen, if that is what you are requesting.

Here is a profile after installing my extension in Firefox Nightly with the "Native Allocations" feature enabled: https://share.firefox.dev/3ql5PxV. This is when loading the databases from the browser cache.

Here is another profile when updating the databases over the network, when the issue does not occur: https://share.firefox.dev/3OJuxlN.

Attached file memory-report.json.gz —

(In reply to Julien Wajsberg [:julienw] from comment #5)

  • For memory usage issues, capture a memory dump from about:memory and attach it to this bug.

Attached is the requested memory dump. Please let me know if you need any more information.

This part seems to be the issue:

6,510.65 MB (100.0%) -- explicit
├──6,355.10 MB (97.61%) -- workers
│  ├──6,351.56 MB (97.56%) -- workers(121d5ec6-4a6e-42a6-838b-8ee0cf7142d5)/worker(worker.js, 0x2308137d100)
│  │  ├──6,282.99 MB (96.50%) -- zone(0x230e53d8200)
│  │  │  ├──3,847.20 MB (59.09%) -- strings
│  │  │  │  ├──1,720.00 MB (26.42%) -- string(length=399520380, copies=2, "281470698520576,281470698520831,US,California,San Jose,37.33939,-121.89496/n281470698520832,281470698521599,CN,Fujian,Fuzhou,26.06139,119.30611/n281470698521600,281470698521855,AU,Tasmania,Glebe,-42.874638,147.328061/n281470698521856,281470698522623,AU,Victoria,Melbourne,-37.814007,144.963171/n281470698522624,281470698524671,CN,Guangdong,Guangzhou,23.127361,113.26457/n281470698524672,281470698528767,JP,Tokyo,Tokyo,35.689497,139.692317/n281470698528768,281470698536959,CN,Guangdong,Guangzhou,23.127361,113.26457/n281470698536960,281470698537983,JP,Hiroshima,Hiroshima,34.385868,132.455433/n281470698537984,281470698538239,JP,Miyagi,Sendai,38.26699,140.867133/n281470698538240,281470698539007,JP,Hiroshima,Hiroshima,34.385868,132.455433/n281470698539008,281470698539263,JP,Hiroshima,Niho,34.36994,132.49395/n281470698539264,281470698541055,JP,Hiroshima,Hiroshima,34.385868,132.455433/n281470698541056,281470698541311,JP,Shimane,Izumo,35.367,132.767/n281470698541312,281470698541567,JP,Yamaguchi,Yamaguchi,34.183,131.467/n" (truncated))
│  │  │  │  │  ├──1,720.00 MB (26.42%) ── malloc-heap/two-byte
│  │  │  │  │  └──────0.00 MB (00.00%) ── gc-heap/two-byte
│  │  │  │  ├────864.00 MB (13.27%) -- string(length=200565128, copies=2, "16777216,16777471,US,California,San Jose,37.33939,-121.89496/n16777472,16778239,CN,Fujian,Fuzhou,26.06139,119.30611/n16778240,16778495,AU,Tasmania,Glebe,-42.874638,147.328061/n16778496,16779263,AU,Victoria,Melbourne,-37.814007,144.963171/n16779264,16781311,CN,Guangdong,Guangzhou,23.127361,113.26457/n16781312,16785407,JP,Tokyo,Tokyo,35.689497,139.692317/n16785408,16793599,CN,Guangdong,Guangzhou,23.127361,113.26457/n16793600,16794623,JP,Hiroshima,Hiroshima,34.385868,132.455433/n16794624,16794879,JP,Miyagi,Sendai,38.26699,140.867133/n16794880,16795647,JP,Hiroshima,Hiroshima,34.385868,132.455433/n16795648,16795903,JP,Hiroshima,Niho,34.36994,132.49395/n16795904,16797695,JP,Hiroshima,Hiroshima,34.385868,132.455433/n16797696,16797951,JP,Shimane,Izumo,35.367,132.767/n16797952,16798207,JP,Yamaguchi,Yamaguchi,34.183,131.467/n16798208,16798463,JP,Shimane,Matsue,35.467,133.05/n16798464,16798719,JP,Tottori,Kurayoshi,35.433,133.817/n16798720,16798975,JP,Tottori,Tottori,35.500111,134.232839/n16798976,16799231,JP,Shimane,Ma" (truncated))
│  │  │  │  │    ├──864.00 MB (13.27%) ── malloc-heap/two-byte
│  │  │  │  │    └────0.00 MB (00.00%) ── gc-heap/two-byte
│  │  │  │  ├────782.86 MB (12.02%) ++ (5343 tiny)
│  │  │  │  ├────406.37 MB (06.24%) -- string(<non-notable strings>)
│  │  │  │  │    ├──406.35 MB (06.24%) -- gc-heap
│  │  │  │  │    │  ├──406.35 MB (06.24%) ── two-byte
│  │  │  │  │    │  └────0.00 MB (00.00%) ── latin1
│  │  │  │  │    └────0.02 MB (00.00%) ++ malloc-heap
│  │  │  │  └─────73.96 MB (01.14%) ── string(length=2, copies=3231317, "US")/gc-heap/two-byte
│  │  │  ├──2,014.59 MB (30.94%) -- realm(web-worker)
│  │  │  │  ├──2,014.48 MB (30.94%) -- classes
│  │  │  │  │  ├──2,014.27 MB (30.94%) -- class(Array)/objects
│  │  │  │  │  │  ├──1,870.27 MB (28.73%) ── gc-heap
│  │  │  │  │  │  └────144.00 MB (02.21%) -- malloc-heap
│  │  │  │  │  │       ├──144.00 MB (02.21%) ── elements/normal
│  │  │  │  │  │       └────0.00 MB (00.00%) ── slots
│  │  │  │  │  └──────0.20 MB (00.00%) ++ (2 tiny)
│  │  │  │  └──────0.12 MB (00.00%) ++ (5 tiny)
│  │  │  ├────335.81 MB (05.16%) ── unused-gc-things
│  │  │  ├─────84.99 MB (01.31%) ── gc-heap-arena-admin
│  │  │  └──────0.40 MB (00.01%) ++ (9 tiny)
│  │  └─────68.57 MB (01.05%) ++ (4 tiny)

It looks like the garbage collector is failing. This would explain what I am experiencing, as the Web Worker is paused waiting for the garbage collector to complete, but the garbage collector is not working as expected, so it causes an indefinite hang in the worker.

Attached image image.png —

I have noticed that the CPU usage for the extension process periodically gets stuck at 100%, which can be seen from about:processes.

The attached screenshot shows what about:processes looks like when the issue occurs.

Note that this issue is severely affecting users of my "Server Status" add-on.

Nothing looks weird from the profile. Indeed we're retaining 1G of data but I believe this is expected from how the addon works.

I'm moving this to the GC component, in case my GC colleagues will be able to see more things.

If you can reproduce easily locally, and if you can confirm that the issue is new, maybe you could help pinpoint a specific change by running mozregression => https://mozilla.github.io/mozregression/quickstart.html

Component: General → JavaScript: GC
Product: WebExtensions → Core

:jonco can you tell if this is a GC issue?
Comparing the two profiles from comment 7, the worker thread follows a similar pattern, but the GC sweep (at around 70s in both profiles) cleans up around 1GB of memory in one but cleans up almost nothing in the one where the problem occurs.

Flags: needinfo?(jcoppeard)

If I had to guess, I would pin-point the line 58 as the source of the problem if the file content is huge.

What is being reported in the memory profile is that we have some very large arrays.
What is being reported in the profiler, is that we are spending a lot of time marking strings.

Line 58, split by new lines, then extract quoted strings.
I would recommend fixing the code to repeatedly call String.prototype.match to find the next match each time, in order to avoid keeping a lot of retained strings around, which are kept alive by some very large arrays.

Otherwise, Jon or Steve might provide a in-machinery feedback.
I doubt there is anything specific that we can do in this case, unless we were able to prune the marking phase for any new objects that are unvisited since they were generated, as this might require extra complexity in the GC.

Still one question, do we have any GC budget on worker threads?

(In reply to Bryan Thrall [:bthrall] from comment #11)

Comparing the two profiles from comment 7, the worker thread follows a similar pattern, but the GC sweep (at around 70s in both profiles) cleans up around 1GB of memory in one but cleans up almost nothing in the one where the problem occurs.

To be clear, both profiles in comment 7 are "good", while the profiles in comment 1 and comment 6 are "bad". The issue you are seeing between the two comment 7 profiles is likely a separate bug, but it does not cause as serious of side effects as the 100% CPU usage and hang in the extension process that are described in this bug.

It looks like what is happening is that the worker is continually triggering GC because the heap size is close to its limit, and these collections aren't freeing anything. In this situation we are supposed to fail hard with an out of memory exception but it looks like that isn't happening.

I don't know of any change that went into 113 that would have caused this.

From the memory report It looks like the worker is holding onto a bunch of large strings (4 strings that are 100s of MBs) as well as a bunch of other data. This may indicate a leak in the worker. Alternatively there may be a way of writing the worker to load data more incrementally and avoid holding onto so much at any one time.

(In reply to Nicolas B. Pierron [:nbp] from comment #12)
Thanks for looking into this (I wrote the comment above before I saw your reply). Yes that does look something that would cause this problem to manifest.

Still one question, do we have any GC budget on worker threads?

I don't think so. Incremental GC for workers is something that has been proposed elsewhere and would be nice to have. But really GC scheduling for workers is very basic and could use a complete overhaul.

(In reply to Julien Wajsberg [:julienw] from comment #10)

If you can reproduce easily locally, and if you can confirm that the issue is new, maybe you could help pinpoint a specific change by running mozregression

As noted in comment 0, I can confirm that this issue is "new", as at least one other user of my add-on (who is also on the CC list for this bug) has reported the issue to me. However, I cannot easily reproduce it locally. I have recently noticed that the issue seems to occur more reliably if the system is idle for the duration of the geolocation database update, but it is still difficult to reproduce on demand.

(In reply to Nicolas B. Pierron [:nbp] from comment #12)

I would recommend fixing the code to repeatedly call String.prototype.match to find the next match each time, in order to avoid keeping a lot of retained strings around, which are kept alive by some very large arrays.

Yes, there are several improvements that I could potentially make to this code, which I probably will do in a future update of the extension, but that does not change the fact that there is a serious Firefox bug here. I actually already published an emergency update for the add-on on May 21 hoping to work around this issue, but it had no effect, which is why I filed this bug shortly after on May 23. In my next update I am planning to convert the databases to TSV format, which will allow me to greatly simplify that line 58 by eliminating the RegEx and the need extract quoted strings, but I doubt it will have any effect on this bug.

(In reply to Jon Coppeard (:jonco) from comment #14)

From the memory report It looks like the worker is holding onto a bunch of large strings (4 strings that are 100s of MBs) as well as a bunch of other data. This may indicate a leak in the worker.

The worker is not holding onto any large strings. As explained in comment 6, it parses those databases in CSV format and converts them into a compact 2D array, which is stored in memory in the worker, but it is not retaining anything else. This should be at most around 300 MiB of memory total for both databases combined. There are a lot of duplicate small strings (for the names of cities, states/providences/regions and country codes), but it looks like Firefox is smart enough to not store multiple copies of those, which should help to significantly reduce memory usage. If there is a memory leak in the worker, it is not in my code.

To expand on my comment 13 from above, the two profiles in comment 7 show what is supposed to happen. As you can see, the whole database update should take around 1 minute and at the end, the Web Worker should only be using around 300 MiB of memory. (Users can alternatively select a much smaller database on the options page, which would only use a few MiB of memory.) The first profile in comment 7 also shows a different but possibly related bug, which causes it to use more memory than this. However, when the issue occurs, the database update hangs and the CPU usage for the Firefox Extension process gets stuck at 100% indefinitely. This can be best seen by the profile in comment 6, which was around 7 minutes, the maximum time allowed with the default 1 GiB profile buffer. When the issue occurs, the memory usage for the Firefox Extension process is also stuck at around 6.5 GiB, which is much higher than it should ever be. This can be seen from the memory dump attached to comment 8. The two default databases are currently 191.3 MiB and 381.0 MiB uncompressed for IPv4 and IPv6 respectively, so even if it has to briefly store two full copies of the largest database, it should only be using a maximum of 762 MiB at any given time and only for a few seconds at most. By "indefinitely", I really mean it says hung at 100% CPU usage forever, until either Firefox is killed or the extension is disabled. I left Firefox open for several hours to confirm that the issue would never resolve itself. As I mentioned above, it looks like the garbage collector is failing and getting stuck in an infinite loop. I would be happy to increase the profile buffer and create a much longer profile of the issue if that would help.

While these default databases are certainly large, they are nowhere near the JS limits. For JS arrays, according to MDN they can have up to 2^32 - 1 elements, which is over 4.2 billion. The two default databases currently have 3,120,022 and 4,504,439 rows for IPv4 and IPv6 respectively, which is of course several orders of magnitude less than that limit. For JS strings, according to MDN the maximum length is 2^53 - 1 (8 PiB), but in Firefox they are artificially limited to 2^30 - 2, which is exactly 1 GiB (or 2 GiB in the pesky UTF-16 encoding) and almost three times larger than the largest database.

Could this be triaged based on the info already provided?

status-firefox114: affected → wontfix
status-firefox116: --- → affected
Flags: needinfo?(wmedina)

Assuming that the evaluation from comment 14 is accurate, There is work to be done considering the heap size and limits verification of it when dealing with workers, but this seems like a corner case that is most of the time unexpected.

Also, it might be faster to handle this bug as part of the extension rather than waiting on a fix for this issue as part of Firefox to be available in a released version.

Thanks for the report.

Severity: -- → S4
Flags: needinfo?(wmedina)
Priority: -- → P2

(In reply to Nicolas B. Pierron [:nbp] from comment #18)

Also, it might be faster to handle this bug as part of the extension rather than waiting on a fix for this issue as part of Firefox to be available in a released version.

Thanks for the response. However, I am not sure what specifically you are suggesting that I do as an extension developer to work around this serious Firefox regression. Maybe I am misunderstanding something, but if there were a possible workaround, as explained in comment 16, I obviously would have already implemented it 3+ weeks ago before filing this bug. Yes, there are a few minor potential optimizations I could make to the worker, such as the one suggested in comment 12. However, if the Firefox garbage collector is broken as it seems, then this will make no difference on the issue. It does not matter how much I drag out the memory allocations if the memory is never freed, as the end result will still be the same...

I am planning to publish another update in a week or so that along with the other changes described in comment 16 will also change it to update the two databases sequentially instead of in parallel, which should approximately half the maximum RAM usage. However, again, if the Firefox garbage collector is broken, I very much doubt that this will have any effect on the issue other than just delaying the inevitable hang in the Firefox extension process. This cannot be understated, this bug has been absolutely catastrophic for my add-on, which can be seen from the number of responses to my uninstall survey over the last few weeks. Users do not understand that this is a Firefox bug, so there is nothing as an extension developer I can do about it.

Please reconsider fixing Firefox 115. This very serious regression cannot be allowed to stand for a whole year for ESR users. If the bug is in Firefox's Web Worker implementation as implied by comment 14, it is most likely effecting much more than just my add-on.

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

Platforms: [x] Windows [x] macOS [x] Linux [x] Android
Impact on browser: Causes noticeable jank
Configuration: Rare
Websites affected: Rare
Resource impact: Severe
[x] Able to reproduce locally

Performance Impact: ? → low
Keywords: perf:resource-use, perf:responsiveness, reproducible

I had another look at the latest data that I missed earlier.

From both the memory report in comment 8 and the native allocations profile from comment 7, I think the response object stays in memory and isn't garbage collected. Incidentally this is in line with the initial description from the reporter.

In the memory report:

  • the 2 big strings are clearly the original CSV file, not the parsed strings
  • moreover we see each of them twice

The result of the parse (the many smaller strings) seems much smaller.

In the profile, you can look at this view: https://share.firefox.dev/3NXKR1b
This uses the "native allocations" feature by using the option "Retained Memory" in the web extensions process, with the inverted call tree so that the heaviest leaf nodes are shown first.
We clearly see that the biggest retained memory node comes from the result of decoding the response body to text.

To know why the response is retained, maybe the memory devtools could help as well. It's not super user friendly, but it makes it possible to see the retaining path.

Given the age of this bug, it would be good to know if the issue still happens now. If yes, it would be good to that we reproduce with a simpler test case (for example a worker doing just a big fetch in a normal webpage?) and see what's happening.
Also it would be good to see profiles and memory dump from a Firefox version that doesn't have the bug.

Thanks for your patience.

needinfo to the reporter in case you're still interested to help us with that.

Flags: needinfo?(tdulcet)

Yes, I am happy to help in any way I can to get this fixed. Please let me know specifically what you need me to do.

Given the age of this bug, it would be good to know if the issue still happens now.

Yes, this bug is still reproducible. I did make those changes to my add-on described in comment 19, which seems to have significantly reduced the number of occurrences of the issue, but it still does occur. What seemed to make the biggest difference was changing the add-on to update the two databases sequentially instead of in parallel. Reverting that one change mostly restores the behavior described in comment 0, where the bug happens around 50% of the time.

Since I filed this bug, I have seen similar issues with webpages that use a lot of memory (where they can sometimes hang), so this bug may not affect just Web Workers, but it is harder to reproduce.

Flags: needinfo?(tdulcet)

Thanks for confirming you still see this.
Ideally I'd like to see the result of running the addon with a version of Firefox that doesn't have the problem (Firefox 112 if I understand properly): a "native allocations" profile as well as a about:memory dump.

I installed the latest version of Server Status and measured the memory in about:memory, I can still see the responses being retained, but now it's just one copy of each instead of 2 before.

Can you please test whether removing this line fixes the issue for you?
https://github.com/tdulcet/Server-Status/blob/d5393abddd60516f1e46aad52ae906a2ddb56495/worker.js#L91

Sorry I misread the code: this line is only for errors, not for successes, so please ignore this request.

Thank you for looking into this bug again.

The latest version of the add-on requires Firefox 114 or greater and the older versions no longer work (due to changing the databases from CSV to TSV format on January 1, as described in comment 16). However, I could revert some of these changes to the add-on if needed to restore compatibility with older versions of Firefox.

I installed the latest version of Server Status and measured the memory in about:memory, I can still see the responses being retained, but now it's just one copy of each instead of 2 before.

Yes, I see that as well, which may be part of the problem here, as the full CSV/TSV files obviously should never be retained, only the parsed result which is significantly smaller. As you saw from the code, the TSV file is stored in a const variable, which of course should be automatically garbage collected when the variable goes out of scope, just before the function returns.

For the two copies to be retained, I believe you would need to wait 24 hours after installing the add-on for the automatic update of the databases to occur. Presumably, it is retaining both the old and new copies of the two TSV files, which is a major memory leak.

STR:

  1. Open the attachment.
  2. Click Run. Wait until "end" appears (shouldn't be long)
  3. Go to about:memory
  4. Press "minimize memory usage" then "Measure".
  5. Notice that the big string is retained even though it shouldn't (this is the string with \t characters)

This testcase uses a Blob URL in fetch so that you don't need to fetch an actual file. I called revokeObjectURL so this shouldn't be the cause of the issue. Also I see the same issue with a HTTP fetch.

I'd like to note that I'm seeing the same behavior from older Firefox versions too, so this might be something different than what you where seeing. But we don't know for sure unless we can run an older version of your addon in Fx 112.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: