Bug Reports | XmrBazaar

Awiteb

5 (9)

Posts: 3

Earned: 0 XMR

Tipped: 0 XMR

Jul 15 12:21

(0)

#1672

I'm unable to make my mediator listing #Mz8kp public. After unchecking the 'Private' checkbox and saving, the listing remains private. When I return to the edit page, the checkbox is checked again.

Tip Monero to Awiteb

842PfDv59Z9aMk9ZTfGZwDKJGoJcSSCgoU3tdL9VpsWr1KudSu7cdNjfYtrQiJjuuaWHAEnq4cHgGLWUQKxzSgESD4CVHvr

Publish Tip to Awiteb

Please login to publish your tip

xxxb

5 (1)

Posts: 4

Earned: 0 XMR

Tipped: 0 XMR

Jul 22 15:50

(0)

#1734

Reply to post #29

BUG: the anonbazaar .onion link mentioned in the FAQ seems not to be working. I am not an expert in TOR's hidden services, but the .onion address of XmrBazaar and anonbazaar seem identical to me, idk if that causes the problem?

Tip Monero to xxxb

86xNNjAkzow1ro7c9eyeBrRiJ9DvL9jicDYCFrrhPUYtThuZ86SS33g3ZYUr9iD6S8JnvctTfEwm7NR97PqtMEUz8B3dYzp

Publish Tip to xxxb

Please login to publish your tip

BlankReindeer34

N/A (0)

Posts: 1

Earned: 0 XMR

Tipped: 0 XMR

Jul 26 10:33

(0)

#1780

had 1 item on my wishlist, but it is deactivated or deleted, so I still see Wishlist (1) but it shows no listings in it.

show us deactivated/deleted items so we can remove them from wishlist again or do it for us in this situation.

Tip Monero to BlankReindeer34

BlankReindeer34 has not setup a {COIN} tip address yet.

Publish Tip to BlankReindeer34

BlankReindeer34 has not setup a {COIN} tip address yet.

AuroraGeneralStore

5 (8)

Posts: 10

Earned: 0 XMR

Tipped: 0 XMR

Aug 3 12:13

(1)

(0)

#1849

Reply to post #1386

We are having the same problem here.

Tip Monero to AuroraGeneralStore

AuroraGeneralStore has not setup a {COIN} tip address yet.

Publish Tip to AuroraGeneralStore

AuroraGeneralStore has not setup a {COIN} tip address yet.

SpaleRuby

N/A (0)

Posts: 3

Earned: 0 XMR

Tipped: 0 XMR

Aug 10 01:05

(0)

#1886

Forum tip placeholder leak: when a post author has no forum tip address, both tip panels render the literal text `username has not setup a {COIN} tip address yet.`

Reproduced logged out on current topic pages, including topics 316 and 337. Authors with a configured address correctly get `Tip Monero to username`, so this is separate from whether the address is set.

Expected: resolve `{COIN}` to `Monero` on XmrBazaar (or use `has not set up a Monero forum tip address yet`). The same template may need the configured/no-address branches checked separately on AnonBazaar, where the coin can differ.

Tip Monero to SpaleRuby

43DExbvtqdbE9oEhh3GtZzj6uBxZermjgFkac3V3nSPobHYoEUzFEetjEcGmbBRi6veFwQSC8Kf6ycpLnZZDnrnuDecm8Bg

Publish Tip to SpaleRuby

Please login to publish your tip

felixfi008

N/A (0)

Posts: 1

Earned: 0 XMR

Tipped: 0 XMR

Aug 16 15:04

(1)

(0)

#1912

"Access blocked
Referer is required by tile usage policy of openstreetmap's volunteer-run servers"

I keep getting the above message plastered all over the map page. Regardless of whether I'm logged in.

TOR browser JS setting in standard mode.

Tip Monero to felixfi008

felixfi008 has not setup a {COIN} tip address yet.

Publish Tip to felixfi008

felixfi008 has not setup a {COIN} tip address yet.

Camylopez

5 (37)

Posts: 38

Earned: 0 XMR

Tipped: 0 XMR

Aug 19 04:37

(0)

#1920

When confirming that trade has been paid, you are presented with the option of inputting transaction id and transaction key.

Every time I submit a transaction key generated via cake wallet it’s accepted.
Every time I submit a transaction key generated via my ledger, it’s rejected as invalid.

I’ve been dismissing it so far, but it’s every single time, so has to be some bug.

I’m using my ledger through cake wallet, so it is using same app in each case.

The version of cake wallet I’m using is the xmr only one, so monero.com

Edit; ok thanks to soalreaver, this is not a bug on XmrBazaar part, but a feature of ledger devices. They encrypt the key.
I will leave it so if anyone else has same issue will know

Edited: Aug 19 06:43

Tip Monero to Camylopez

87V1oyh1q7Zh2ma2i15DG5Ywwj6wjSYYPEHuPnX3hkTMKqaCe9LvVQpZc5C4Fe6QeCXfyWHruQAP4Y6v5WSXAutE2S7vLVV

Publish Tip to Camylopez

Please login to publish your tip

m3c

5 (11)

Posts: 2

Earned: 0 XMR

Tipped: 0 XMR

Aug 19 14:47

(0)

#1925

I canceled an order and was prompted I could still leave a review.

"This order was canceled. However you may choose to leave an optional review. If you do not want to review this order, you may leave it blank."

Tried leaving a positive review, but get "error_invalid_order_status".

Not a huge deal, but it appears a canceled order is no longer valid (so you can't leave a review?)

I love XMR Bazaar

Tip Monero to m3c

8BFmjJmgz7YM7WTt7zJcMYaLdCWyLZ7nPV2NTwkVeiw48k6QMi2un8zXGDPaLVPF8EWVUNN4thyeZU4CRzNLwd35UbsoHmJ

Publish Tip to m3c

Please login to publish your tip

knitmachine

5 (4)

Posts: 2

Earned: 0 XMR

Tipped: 0 XMR

Aug 25 17:48

(1)

(0)

#1962

It's not possible to create auctions with physical item shipping because the shipping detail fields are missing (shipping costs etc.) on the auction form.

Tip Monero to knitmachine

knitmachine has not setup a {COIN} tip address yet.

Publish Tip to knitmachine

knitmachine has not setup a {COIN} tip address yet.

MtGoxGuide

N/A (0)

Posts: 1

Earned: 0 XMR

Tipped: 0 XMR

Aug 27 14:00

(0)

#1966

Hello. My one and only listing got broken. The attached PDF file wont download. I cananot delete the old file or add a new one. Now after I tried, all past transactions of that listing are also gone, so now payed transactions cannot rate the listing. Please fix it.

Edited: Aug 27 14:13

Tip Monero to MtGoxGuide

MtGoxGuide has not setup a {COIN} tip address yet.

Publish Tip to MtGoxGuide

MtGoxGuide has not setup a {COIN} tip address yet.

SoulReaver

5 (4)

Posts: 105

Earned: 0.003 XMR

Tipped: 0 XMR

Aug 29 03:07

(0)

#1972

Messenger WebSocket (/ws/msg/) appears to close (1006) when the mobile tab is hidden, and does not seem to reconnect

Up front: we might be wrong about some of the details below (hopefully not), and where we are unsure we have said so. But the socket closing is a real issue, we hit it repeatedly and a few other people have mentioned running into it too.

Feature: Built-in messenger
Endpoint (observed): wss://xmrbazaar.com/ws/msg/
Impact: On mobile, realtime messaging seems to stop after the phone sleeps or the user switches apps, and does not appear to come back on its own.

What we are confident about: this is recurring and repeatable. The messenger connection drops and does not come back on its own after the mobile tab is hidden; we have hit it many times in normal use, a few others have mentioned the same thing, and we reproduced it deliberately below.

What we could check in code: the client-side messenger script that ships to the browser (/js/messenger/websocket.js and actions.js) is public, so the parts about what the client does on close are read straight from that code, not inferred. Those are marked below as from the client code.

What is still guesswork: the cause of the close itself, the timing, and anything server-side. We cannot see what closes the socket, only how the browser behaves around it, captured over chrome://inspect on a real phone. You will have a much better view of the server side than we do.

What we saw

With the messenger open and a conversation active on mobile, if the tab goes into the background (switching apps, or the screen turning off), the WebSocket seems to close a few seconds later with code 1006. On returning to the tab, it looks like no new connection is made. The messenger shows "Error: Websocket connection closed", and the conversation shows "No connection. Please copy your draft message first, then refresh the page to reconnect." In our runs a full page reload was the only thing that brought it back, though we did not test every recovery path.

Logs

Three runs on the messenger page with a conversation open, logging the live messenger_globals.socket events and tab visibility, over chrome://inspect against a phone.

A couple of caveats on the method, since they affect how to read these. chrome://inspect keeps showing the last frame on the desktop while the phone tab is actually hidden, so a recording can look foreground when the tab was backgrounded; we are trusting the VISIBILITY log lines over the image. Mobile browsers also seem to suspend timers in a hidden tab, so the final export printed on resume rather than at the close; the per-event timestamps should still reflect when each event fired, but we cannot fully vouch for timer accuracy across the suspend.

The three run event logs (start, message, visibility, and close events with timestamps) are in the attached logs folder: run1-app-switch, run2-screen-off, run3-foreground-idle, plus a 30-minute trollbox control run. Runs 1 to 3 are transcribed from the console shown in the screen recordings, faithful to what was on screen but not the raw export files; the raw exports and the control run are in the folder. The key values are stated in the reading below.

How we read these (best guess)

This is inference from three runs, not a diagnosis. Take it as a starting point for someone who can see the logs and code.

The close seems tied to the tab being hidden rather than to the socket being idle. Runs 1 and 2 both closed 1006 roughly five seconds after VISIBILITY hidden (about 5.0s and 5.2s). Run 3 stayed open for 150 seconds in the foreground with only occasional frames and did not close in that window. That is only three runs, so we would not call it conclusive, but it is consistent.

The repeated ~5s gap between hidden and close in the two drop runs might suggest a fixed timeout somewhere on that socket's path, as opposed to random network loss. That is a guess worth checking against server timeouts, not something we can confirm from outside.

In the runs where it closed, we did not see an OPEN event after the tab became visible again, and readyState stayed 3. That is what makes us think it is not reconnecting on its own, but we are only inferring that from the absence of a log line, and we have not seen whatever reconnect logic may or may not exist.

The endpoint reads as wss://xmrbazaar.com/ws/msg/ in the START line of all three runs, so that part we are fairly confident about.

Also seen, weaker evidence

The same "connection closed" state seems to show up on the public trollbox too, which uses a different socket (wss://xmrbazaar.com/ws/tb/). We did not instrument that with the same logging, so it is an impression, not proof. If it turns out both sockets behave the same way, it might point to shared connection handling rather than anything specific to the messenger, but that is speculation at this stage.

We have also hit what looks like the same closure during ordinary use while going back and forth between the site and another app, including, from memory and not captured, while filling in a listing. That lines up with the hidden-tab pattern above, but we are noting it as a recollection, not evidence.

From the client code (public script, read directly)

These are read from the shipped websocket.js / actions.js, so they are not guesses, though you would still know the intent behind them better than we do. They line up with why a close stays broken on return:

- onclose only calls show_error(... 'Websocket connection closed'). It does not open a new socket, schedule a retry, or re-init. So once the socket is gone, nothing in the client brings it back.
- There is no visibilitychange, pageshow, online, or focus handler in the client. Nothing runs when the tab comes back to the foreground, which fits what the logs showed: no OPEN after the tab returns.
- onerror and ondisconnect also just show an error. (ondisconnect is not a real WebSocket event, so that one never fires at all.)
- Synchronous sends have a 60s timeout via Promise.race, but the timeout branch does not delete the entry from ws_response_queue, so a timed-out request leaves its resolver stuck. Minor, and not the cause of the close, just noting it while it was in view.
- The ping keepalive in actions.js reschedules only after a successful response and has no foreground-resume hook, so it does not restart a socket that died while hidden.

Source files, readable live:
websocket.js
actions.js

Put together, this is why a real close stays broken when the user returns: the socket closes (cause unknown to us), and the client has no path to reopen it.

If reconnect-on-resume were added, the shape would be something like the following, shown only to convey the idea:

function ensureMessengerConnection() {
const s = messenger_globals.socket;
if (!s || s.readyState !== WebSocket.OPEN) connectMessenger();
}
document.addEventListener('visibilitychange', () => {
if (document.visibilityState === 'visible') ensureMessengerConnection();
});

The part we cannot see (server side, still a guess)

What actually closes the socket about five seconds after the tab goes hidden is not visible to us. It could be a proxy or backend idle timeout on a backgrounded connection, the mobile browser itself, or something else. If a backgrounded or quiet socket is being closed on purpose, that may well be fine, and client-side reconnect on resume would still be what smooths it over for the user. This is the part where you can see what we cannot.

Unrelated, just noticed

The console also showed Uncaught SyntaxError: missing ) after argument list (service-worker.js:193) and a failed ServiceWorker registration on load. Probably nothing to do with the socket, but flagging it since it was right there.

https://drive.proton.me/urls/RFAJSG423M#MJuo5SJnMOwF

Edited: Aug 29 03:11

Tip Monero to SoulReaver

8AJJt5FoxgKapYk69YgSLXPaSBYd88hghg32ie25ZXGSFFYgVeKT4ytLkPoCsnJGE3gQninbK6JDUAX4qNCRUqfXFwXe3Hm

Publish Tip to SoulReaver

Please login to publish your tip

snex

5 (6)

Posts: 13

Earned: 0 XMR

Tipped: 0 XMR

Aug 29 20:52

(1)

(0)

#1980

I am not able to take an escrow-only offer whose price is "make an offer." The site gives an error that there is a minimum price for escrow, but there is nowhere to put in the price I am offering.

Tip Monero to snex

snex has not setup a {COIN} tip address yet.

Publish Tip to snex

snex has not setup a {COIN} tip address yet.

exem

5 (3)

Posts: 1

Earned: 0 XMR

Tipped: 0 XMR

Sep 2 13:18

(0)

#2015

Reply to post #1972

having the same issue here

Tip Monero to exem

exem has not setup a {COIN} tip address yet.

Publish Tip to exem

exem has not setup a {COIN} tip address yet.

anonjpn

5 (3)

Posts: 4

Earned: 0 XMR

Tipped: 0 XMR

Sep 5 06:31

(0)

#2038

Hello.
The email notification function has not been working for several months.

Tip Monero to anonjpn

861R6JyW7vmXTpgJUA3i1QS3QRkRyXZzS9SNjtFntcaWZUNTRVp49jdNPs6yZJ4qUe6hA93LkQtmpDUTwm7ZogbENS2rdtn

Publish Tip to anonjpn

Please login to publish your tip

std_vector

5 (5)

Posts: 10

Earned: 0.011 XMR

Tipped: 0 XMR

Sep 6 14:08

(0)

#2045

XmrBazaar moved to another hosting. So, maybe it's time to enable ipv6?

Tip Monero to std_vector

44DG6jgByodcEaqKimcvm3QYKfxVWFyzvLLQjLVYKbe2f4kx3oLKJuvGTfduW1AXk13hdBdwaBQk18n5F4oEkarr1ULrjtG

Publish Tip to std_vector

Please login to publish your tip

std_vector

5 (5)

Posts: 10

Earned: 0.011 XMR

Tipped: 0 XMR

Sep 7 15:13

(0)

#2049

As I can see current hosting provider supports ipv6 https://mynymbox.io/vps

Tip Monero to std_vector

44DG6jgByodcEaqKimcvm3QYKfxVWFyzvLLQjLVYKbe2f4kx3oLKJuvGTfduW1AXk13hdBdwaBQk18n5F4oEkarr1ULrjtG

Publish Tip to std_vector

Please login to publish your tip

glamorous_oak

5 (76)

Posts: 33

Earned: 0 XMR

Tipped: 0 XMR

Sep 8 13:55

(0)

#2062

onion site does not set "remember_me" cookie unlike clearnet site resulting in logout

Tip Monero to glamorous_oak

852XVfJZLuXC5FGqTNXdKB7c8AwLgWgTfH8Kr2P48VAAKbGSXyBXV2qDYwyHScfGhTRLaM1C3CdzogtgUAeZVxQC7hw4KHy

Publish Tip to glamorous_oak

Please login to publish your tip

SoulReaver

5 (4)

Posts: 105

Earned: 0.003 XMR

Tipped: 0 XMR

Sep 8 20:57

(0)

#2065

Escrow stuck at payout: signer2 rejects a transaction signer1 successfully generated

Web client, 2026-09-08. 2-of-3 escrow, decision payout, agreed by buyer and seller, so signer1 is the buyer and signer2 is the seller. Amount 0.001959401207 XMR plus 0.001 mediator fee.

This was a deliberate test escrow.

Symptom

Stage 4 of 4. The platform shows "Waiting for seller to sign tx". The seller's client raises "Unsigned TX outputs don't match" and will not sign. There was no way forward from inside the tool. We tried cleaning the data and letting it rebuild.

This is not "stale multisig data"

The guide documents that error for a cleared IndexedDB between export_multisig_info and sign_tx. This is a different error, and IndexedDB was intact throughout.

signer1 completed generation

From the buyer session, IndexedDB database "escrows", store "wallet_backups", field wallet_state:

loaded, restored, prepare_multisig, make_multisig, finalize_multisig, complete_multisig, restored, make_deposit, check_deposit, make_decision, export_multisig_info, import_multisig_info, generate_tx, restored

The buyer's own log agrees. On reload at 06:26 and again at 07:12, the queue replays and reports prepare_multisig, make_multisig, finalize_multisig, complete_multisig, make_deposit, check_deposit, make_decision, export_multisig_info, import_multisig_info and generate_tx all "already done", then "queue is done".

The escrow backup taken at the time also contained a complete unsigned_tx_signer1 blob, roughly 8 KB of multisig txset. So a transaction genuinely exists. signer2 is rejecting a real payload, not an absent one.

Error handling

Whatever the underlying cause, the failure mode deserves attention on its own. generate_tx marked itself complete and was removed from signer1's queue, and on every subsequent reload the queue reports it "already done" and idles. But its output is one signer2 will not accept. So either the step succeeded and the validation on signer2's side is wrong, or the step produced a bad payload and advanced anyway. Either way nothing verified the result before the queue moved on, and there is no retry path once it has.

The consequence is a terminal state no participant can clear. signer1's queue is permanently satisfied. signer2 fails on every attempt. Neither can reset, regenerate or back out from the UI, and the escrow sits at 96% indefinitely. Marking a step complete should depend on its output being usable by the next step, and a payout stage that can fail this way needs an operator-visible way to regenerate.

In the buyer's state:

escrow_signer1 = { "public_view_key": "", "role": "buyer" }
my_public_view_key = { "role": "buyer", "public_view_key": 1, "address": "" }

my_public_view_key.public_view_key holds the integer 1 instead of the 64-character hex. Every other copy of that field is correct, including public_view_key_buyer, public_view_key_buyer_to_publisher and public_view_key_publisher, and role and address within that same object are correct.

I am not claiming this caused the failure. generate_tx ran to completion, so any signer1 identity check reading this field evidently did not block it. Flagging it because a single field holding an integer where every sibling holds hex looks like a bad assignment somewhere, and it may or may not be related.

Other possibility

In this escrow the payout address and the mediator address were identical, so the transaction's two destinations resolve to a single address. Untested, but an output check that keys on address rather than matching a multiset could mismatch on that alone.

Also observed, possibly unrelated

Security Error: page may not load or link to file:///
404 on https://xmrbazaar.com/js/lib/monero.worker.js.map

Tip Monero to SoulReaver

8AJJt5FoxgKapYk69YgSLXPaSBYd88hghg32ie25ZXGSFFYgVeKT4ytLkPoCsnJGE3gQninbK6JDUAX4qNCRUqfXFwXe3Hm

Publish Tip to SoulReaver

Please login to publish your tip

WiseGuy92

5 (2)

Posts: 2

Earned: 0 XMR

Tipped: 0 XMR

Sep 13 16:28

(0)

#2084

When scanning the escrow QR code with wallets on Graphene OS, it didn't detect the QR code. On iOS it detected it.

Also the constant timeouts like web socket or no connection errors are tedious.

Tip Monero to WiseGuy92

WiseGuy92 has not setup a {COIN} tip address yet.

Publish Tip to WiseGuy92

WiseGuy92 has not setup a {COIN} tip address yet.

Juanperez7

5 (2)

Posts: 7

Earned: 0 XMR

Tipped: 0 XMR

Sep 14 14:05

(0)

#2089

Make choosing a location on the map easier. PLEASE.

Tip Monero to Juanperez7

Juanperez7 has not setup a {COIN} tip address yet.

Publish Tip to Juanperez7

Juanperez7 has not setup a {COIN} tip address yet.