[Pixeldrain.com] The download buttons seem to no longer work

[Noldere]

As far as I can tell, nothing else appears to be different on the site. I can login and upload files just fine for example; however, downloading files no longer seems to work on Palemoon for me.

Here's what I have from a download attempt of a simple test text file on a fresh install of version 33.6.1 x64 on Windows 11:

Developer Tools Web console messages:

Code: Select all

received request to open file 0  
file_viewer.js:7:418905
Initializing stats socket  
file_viewer.js:7:220811
Socket is closed, command Object { type: "file_stats", data: Object } added to queue  
file_viewer.js:7:221759
opening file Object { id: "gT12BaHz", name: "Test File (Extra Sad).txt", size: 38, views: 1, bandwidth_used: 0, bandwidth_used_paid: 152, downloads: 1, date_upload: "2025-03-29T00:13:17.997Z", date_last_view: "2025-03-29T00:13:17.997Z", mime_type: "text/plain; charset=utf-8", 18 more… }  
file_viewer.js:7:293652
loading text file gT12BaHz  
file_viewer.js:7:247577
WS update Object { type: "file_stats", file_stats: Object }  
file_viewer.js:7:221020
WS update Object { type: "limits", limits: Object }  
file_viewer.js:7:221020
WS update Object { type: "limits", limits: Object }  
file_viewer.js:7:221020
WS update Object { type: "file_stats", file_stats: Object }  
file_viewer.js:7:221020
File is available, starting download /api/file/gT12BaHz?download  
file_viewer.js:7:361222

No error console messages.

[Moonchild]

Looks like the website is intercepting all normal console messages and user input (it also registers F12 to open the devtools, for example), making it hard to troubleshoot.
Using the raw API call to https://pixeldrain.com/api/file/gT12BaHz?download works just fine, so it's something in their button event scripting, most likely, that's going wrong, but without sensible console output (and obfuscated object/names by dropping everything in an array -- seems to be a new trend!) there's nothing much I can see at a glance. I do see they are using sveltekit, which has been causing various issues in Pale Moon in the past.

[Kris_88]

so it's something in their button event scripting, most likely, that's going wrong,

The problem is probably in the disconnected "a" element.

Code: Select all

var i=document.createElement("a");i.href=t,i.download=e,i.click(),i.remove()

viewtopic.php?f=3&t=28211&p=226955#p226955

[Moonchild]

Code: Select all

var i=document.createElement("a");i.href=t,i.download=e,i.click(),i.remove()

I'm, not sure why they expect this to work. They create a link, dispatch a click on it and immediately remove the entire anchor. Of course that won't result in anything because they don't wait for the event to finish before yanking the element out from under us. This is exactly the kind of mindless scripting thing why use-after-free checks and aborts are necessary.
If they want to use an asynchronous chain like this, then they need to understand this is exactly the kind of thing promises are for, so a browser can ensure processing completes and .then() do the next thing in the chain.

[Shadow]

Not sure, but perhaps this BZ ticket is relevant.

[Moonchild]

Not sure, but perhaps this BZ ticket is relevant.

Seems like it. I'm still thinking this construct shouldn't work, even if in a DOM document, because of bad timing - it's a grey area.

[Kris_88]

I'm still thinking this construct shouldn't work, even if in a DOM document, because of bad timing - it's a grey area.

It looks like it should, regardless of whether it's attached to the DOM

1) It seems that remove() does nothing at all in this case because the element is not attached to the DOM.
https://dom.spec.whatwg.org/#ref-for-do ... e%E2%91%A0

Code: Select all

The remove() method steps are:
If this’s parent is null, then return.
Remove this.

2) It looks like click() is a synchronous operation in this case. Although, I haven't figured it out completely and therefore I'm not sure.
https://html.spec.whatwg.org/multipage/ ... -click-dev

Code: Select all

The click() method must run the following steps:
If this element is a form control that is disabled, then return.
If this element's click in progress flag is set, then return.
Set this element's click in progress flag.
Fire a synthetic pointer event named click at this element, with the not trusted flag set.
Unset this element's click in progress flag.

[Moonchild]

It seems that remove() does nothing at all in this case because the element is not attached to the DOM.

That would just apply to child nodes, though. If it was never attached in the first place, then it isn't a child node of the document.
So I don't think this set of steps applies.

It looks like click() is a synchronous operation in this case.

Click itself might be, but the event handler won't be if it's supposed to trigger a navigation action.

[Moonchild]

Either way, Issue #2721 (UXP) filed.

[Kris_88]

That would just apply to child nodes, though. If it was never attached in the first place, then it isn't a child node of the document.
So I don't think this set of steps applies.

What steps then?
I don't find any other remove(). Even when they talk about the abstract operation of removing a node, the action starts with "Let parent be node's parent." and "Assert: parent is non-null."

https://dom.spec.whatwg.org/#concept-node-remove-ext

[Moonchild]

It's probably an anonymous context. That isn't null, but it's not the DOM or document, either. Like I said it's a grey area -- it's poorly described.

[adoxa]

Here's a Modify HTTP Response filter using the dispatchEvent workaround.

Code: Select all

[["pixeldrain.com",["/file_viewer\\.js/",["i.click()","i.dispatchEvent(new MouseEvent(\"click\"))"]]]]

[Fornax]

Hi people, developer of pixeldrain here. I found this thread when doing some research on what people are saying about my site.

Sorry about the trouble. I want to open the download link with the <a> 'download' attribute so that the save dialog is always triggered. From my research this seems to be the only way to achieve this effect. I tested it in Firefox and Chrome and it seemed to work fine so I assumed it is compliant with the standards.

Pixeldrain's front end is open source, the relevant code can be found here: https://github.com/Fornaxian/pixeldrain ... velte#L100
I do indeed use Svelte, but not SvelteKit.

[Kris_88]

I tested it in Firefox and Chrome and it seemed to work fine so I assumed it is compliant with the standards.

In fact, just because it works in the two browsers you tested doesn't mean it's standard-compliant.
By the way, why are you calling i.remove() if you're not adding the element to the DOM?

[Moonchild]

Hi Fornax,

The issue is that a new <a> element created this way only exists as a reference object in javascript. A click() action is a document event. Unless you attach the element to a document before issuing a click() on it, the event won't be processed because it has no context to fire the event in.

[Fornax]

In fact, just because it works in the two browsers you tested doesn't mean it's standard-compliant.
By the way, why are you calling i.remove() if you're not adding the element to the DOM?

Well, I have not actually read the standards. And if something works on both Firefox and Chrome it means that it works for 99% of the users. I know that it's unfair to the smaller players that the monopolies can create implicit standards like that. But it's always been that way, and most web devs don't have the time to figure out if the specific function they're writing works in all browsers.

I added the remove() call because I was afraid that it would leak memory otherwise. I'm not that well versed on the specifics of javascript, I'm mostly a backend dev.

Hi Fornax,

The issue is that a new <a> element created this way only exists as a reference object in javascript. A click() action is a document event. Unless you attach the element to a document before issuing a click() on it, the event won't be processed because it has no context to fire the event in.

Do I really need to add an element to the DOM that I don't actually want to show to the user? Is there no way to open a download link like that just from pure javascript? The download attribute is important because it lets me control the file name that the file will get.

[Moonchild]

I have not actually read the standards.

We have, see previous posts. It's not well-defined, and implementation differences do exist between browser engines, especially if the standards are ambiguous.

monopolies can create implicit standards like that.

"Implicit standards" aren't standards. If you go by that logic then you might as well not have standards at all and just say "whatever Google does is the de facto standard" and be a monoculture. We are already very close to that, by the way, because Google actually writes a lot of the standards proposals and has for years (for obvious market dominance reasons).

Do I really need to add an element to the DOM that I don't actually want to show to the user?

If you want to dispatch DOM events on it, yes. Not that an <a> with no display content in it will actually show anything to the user, but you do need to add it to the DOM if you want to treat it like a document object. If you're primarily a back-end dev you can compare what you're doing here to creating a database query but not actually executing it, and then being surprised that a stored procedure can't access the data because it's not in the table.

most web devs don't have the time to figure out if the specific function they're writing works in all browsers.

Really? So it's too much work to have a few browsers installed to check web compatibility?
Ironically, for most purposes it's actually true that if it works in Pale Moon, it's almost guaranteed to work in all "mainstream" browsers. So if you're going to limit yourself to just testing it in one browser, use us

The download attribute is important because it lets me control the file name that the file will get.

The problem, once again, isn't the download attribute. The problem is that you create an anchor without attaching it to the DOM and then issuing a (document) click event on it.

[suzyne]

Ironically, for most purposes it's actually true that if it works in Pale Moon, it's almost guaranteed to work in all "mainstream" browsers. So if you're going to limit yourself to just testing it in one browser, use us

This makes a lot of sense!

I maintain some websites and also indulge in trying different UI frameworks for my personal educational purposes, and I do all my running of JavaScript and HTML5 in Pale Moon. Sometimes I wish the Developer Tools were more responsive, but knowing that the files and code are highly standard compliant when they work in Pale Moon, inspires confidence.

[Kris_88]

As far as I remember from what I read a long time ago, Click() passed the event through the DOM, and DispatchEvent() called the event dispatcher directly for the element. Therefore, Click() did not work if the element was not inserted into the DOM. Although, in any case, there is doubt about the functionality when the element can be removed by the garbage collector before the asynchronous loading operation begins to execute. Perhaps this moment is described somewhere in the standards, but I did not look.

[Fornax]

Ironically, for most purposes it's actually true that if it works in Pale Moon, it's almost guaranteed to work in all "mainstream" browsers. So if you're going to limit yourself to just testing it in one browser, use us

I'd love to test my site in Pale Moon, but installing it is not exactly easy. First there's no Flatpak, so it can't be found in the software center. It's not in the Arch repo so I can't install it with pacman either. And I tried downloading the tarball, but it errors out due to a dependency issue (libdbus-glib-1.so.2 can't be found).

I see that there's an AUR install script. But I tend to avoid the AUR because it can cause dependency issues when updates come out. At this point it's not really worth the effort for me.