Export does not export the currently active trace

I used SAML-tracer on two websites:

Our own site
The reference site of the IdP we are trying to add to our service

Despite exporting (1) hours earlier, every time I press export on a fresh (at least I cleared) trace (2), I get the exact same trace as (1). The timestamp is the same and the file content is exactly the same (I checked with md5sum). Changing the cookie filter (mask, remove etc) values did not change anything.

I expect that clearing and collecting a new trace would create a file with only the events that have happened AFTER clearing.

I cannot reproduce this on Firefox (147.0.3) with SAML-tracer (1.9.2). What browser are you using? And do you have other add-ons in place?
Also; can you check with the browser console if something is being blocked (i.e. a CSP violation)

It really happened to me, but export works after closing the tracer window and opening it again. I didn't try just clearing and exporting again. I wonder if the whole thing was fluke. I might try again tomorrow, but I'm not sure, since I got the actual SAML thing working.

I'm using Firefox 147.0.3 and bunch of addons, such as NoScript and uBlock Origin.

Thanks for the addon by the way. It has been very useful.

I also use NoScript, so that's not a problem.
We've seen some strange behaviour in the past with certain add-ons, that's why I was asking.

Same here export doesn't work, Windows 11 PC with Chrome installed (managed browser). I'm not very good at F12, but it looks like the Console tab isn't listing when you press export, but it does list when you click import and a file explorer dialog opens up after clicking import as well.

Hello Just another update. I tried on a fresh machine with an UNmanaged browser and no google account signed in to remove the possibility of a company restriction.

Hello Just another update. I tried on a fresh machine with an UNmanaged browser and no google account signed in to remove the possibility of a company restriction.

I miss the conclusion here.. did it make a difference for you? Did it work, or not?

Hello, I just wanted to validate it wasn't caused by a browser or account being managed by a Google Workspace tenant with potential associated policies. The last update validates this is not the case.

It seems like the export button isn't working correctly.

This export problem happens to me every time I use clear and trace new events. Only reopening saml-tracer helps.

I use the following addons on Firefox (Linux):

Proton Pass
NoScript
uBlock origin
Startpage
And of course saml-tracer

I am not using Private Browsing when testing this. This is my personal computer so it's not affected by group policy or anything like that.

I still can't reproduce this :( Can you see anything in the browser console when you press 'Clear' or 'Export' for the second time?

This is the only error I ever get

AbortError: Actor 'Conduits' destroyed before query 'RuntimeMessage' was resolved 4 ConduitsParent.sys.mjs:383
    _raceResponses resource://gre/modules/ConduitsParent.sys.mjs:383

Is that related?

I tested this again, and I noticed that the problem doesn't necessarily occur on the second export-clear cycle, but so far it has always happened by the third cycle.

I can send you a link to our setup, if I can do that privately

Sure! You can find me at gmai1 under the same username.
I still suspect it's one of your add-ons that's playing dirty here.

@wlinna

Hi @wlinna !
I've followed your reproduction-steps and I'm seeing this:

Is that consistent with the behaviour you are seeing?

More or less yes. So far I haven't seen one which is only 4 bytes large, but the relevant part is that you got two files with identical timestamps. They have the same size too, and most likely their content is identical. You can check it with md5sum to make sure.

@khlr

@khlr Can you help me figure out why this is happening in what seem like very specific conditions?

Unfortunately my notifications had been turned off for quite while... Hence I didn't notice any discussion for the last couple of months. 😵
I'll try to support you in the next days!

@wlinna

So far I wasn't able to reproduce this.
Can you reliably reproduce this issue, @wlinna & @stevenzisblatt or does it just happen occasionally?

Could this be related to a timeout behavior or something like that. Meaning: Did export 1 happen hat some given point in time and export 2 happened e.g. hours later using the same browser & SAML-tracer instance?

@khlr

@khlr Reach out to my username at gmail and I can forward you the reproduction steps that @wlinna sent me. You can see for yourself.

@wlinna

I was able to reproduce the issue following @wlinna's instructions, too.
At some point I noticed this error:

Uncaught SyntaxError: JSON.parse: unexpected character at line 1 column 1 of the JSON data
    createFromJSON moz-extension://dc6543bd-176b-4b88-8698-5c2a8614c5e7/src/SAMLTraceIO.js:180
    reqscopy moz-extension://dc6543bd-176b-4b88-8698-5c2a8614c5e7/src/SAMLTraceIO.js:191
    perform moz-extension://dc6543bd-176b-4b88-8698-5c2a8614c5e7/src/SAMLTraceIO.js:190
    exportRequests moz-extension://dc6543bd-176b-4b88-8698-5c2a8614c5e7/src/SAMLTraceIO.js:26
    createExportResult moz-extension://dc6543bd-176b-4b88-8698-5c2a8614c5e7/src/exportDialog.js:59
    setupContent moz-extension://dc6543bd-176b-4b88-8698-5c2a8614c5e7/src/exportDialog.js:53
    bindButtons moz-extension://dc6543bd-176b-4b88-8698-5c2a8614c5e7/src/ui.js:113

This matches the "no-timestamp.json" export.
But what causes this? My guess: one of the requests involved might be quite "special", causing an error during the JSON serialization.

I just tried an export recently and it worked successfully. Just wanted to report back. If you need any more information please let me know.

I tried again didn't need wlinna's whole step-by-step list to reproduce the error.

When I tried to exported the traces this line from exportDialog.js caused the error:
filteredRequests = httpRequests?.filter(req => req.isVisible && req.isVisible(hideResources, showProtocolRequestsOnly)).map(req => req.parsed);

It yields undefined for a request. Unfortunately I haven't yet figured out which is the erroneous request.
I'd like to figure out why undefined is appearing here in the first place. A "simple" way to resolve the issue, on the other hand, would likely be to simply check that there are no more undefined values in filterRequests afterward.

@khlr

Thanks @khlr ! I'm really a newb when it comes to browser-plugins, so your help is really appreciated!
Would it be possible to output the json to the browser-console so we can figure out what could be the problem?

I'm thinking this is related to #69 as well

Fix null export when requests have no response; add test suite

@khlr

@khlr the undefined appears when a request makes it into httpRequests but never gets a parsed value assigned to it. I'm fairly confident the fix is adding .filter(Boolean) after the .map(req => req.parsed) — that removes those undefined entries before they reach the exporter, so instead of crashing, the export just skips those incomplete requests and includes everything else. That said, replication has proven tricky and I haven't been able to reliably trigger it myself, so I want to think more about testing before opening a PR.

Following up: I've tested both the #106 and #69 fixes end to end using Playwright, loading the extension in a real Chromium instance. For #106 specifically, the test injects an entry with isVisible set but no parsed value and confirms that the export still completes with a fresh timestamp rather than serving a stale cached result. Both tests fail on unfixed code and pass with the fix applied. PR coming shortly.

Fix null export when requests have no response; add test suite (#108)

@closed

@closed in #108

Navigation Menu

Repository navigation

Export does not export the currently active trace #106

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Export does not export the currently active trace #106

Description

Activity

tvdijen commented on Feb 11, 2026

wlinna commented on Feb 11, 2026

tvdijen commented on Feb 11, 2026

stevenzisblatt commented on Feb 19, 2026

stevenzisblatt commented on Feb 19, 2026

tvdijen commented on Feb 19, 2026

stevenzisblatt commented on Feb 26, 2026

wlinna commented on Mar 2, 2026

tvdijen commented on Mar 2, 2026

wlinna commented on Mar 3, 2026

tvdijen commented on Mar 3, 2026

tvdijen commented on Mar 8, 2026

wlinna commented on Mar 9, 2026

tvdijen commented on Mar 9, 2026

khlr commented on Mar 14, 2026

khlr commented on Mar 15, 2026

tvdijen commented on Mar 15, 2026

khlr commented on Mar 29, 2026

stevenzisblatt commented on Apr 2, 2026

khlr commented on Apr 3, 2026

tvdijen commented on Apr 9, 2026

kellenmurphy commented on May 5, 2026

kellenmurphy commented on May 10, 2026

tvdijen commented on May 31, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions