[Bug] Inconsistent Behavior for World Upload

[FlamedDogo99]

Describe the Bug Uploading a vanilla Minecraft world either leads to a crash, or the file uploader won’t dismiss itself Steps to Reproduce

1. Start EaglerCraft client with EaglerMobile userscript
2. Tap the screen to start the client, and wait for it to load
3. Navigate to the main menu by hitting done when presented with the edit profile menu
4. Select single player, create new world, import world, and then upload the world file attached below
5. Observe a crash, or the file uploader not disappearing

Additional Information My user agent:

Mozilla/5.0 (iPhone; CPU iPhone OS 17_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.5 Mobile/15E148 Safari/604.1

Eagler Mobile version: 2.4

Screenshot of the file uplaoder not being dismissed after selecting a file:

The vanilla Minecraft world used in the screenshot: 20 MORE Doors in 100 Seconds! - Copy.zip

[RealPlurr]

Btw it happens only in IOS if someone interested ^^^

[colbster937]

i thought you used android? but yeah this is a really annoying bug

[FlamedDogo99]

If anyone can recreate this issue on other devices and browsers, please leave a comment with the relevant information. (I will be testing it across Safari, Chrome and Firefox on MacOS later tonight.) Currently I just don’t have enough information to troubleshoot this one, especially the crashes.

The current suspects are:

1. this weirdness

   newElement.addEventListener('change', function(e) {
   this.hidden = true;
   })

   I don’t have any justification for this one, but I’m going to try using a document.querySelector for the element instead

2. Reusing elements weirdness

   if(!newElement) {
   this.body.appendChild(element);
   newElement = document.querySelector('input');
   newElement.addEventListener('change', function(e) {
       this.hidden = true;
   })
   }
   newElement.value = null;

   I’m curious if the event listener behaves differently when we manually set its values. I’ll try deleting the element when the event listener is called, and recreating it when the createElement function is called.

Ideally I’d like to figure out why different browser behave differently when reacting to user inputs. The main problem seems to be built-in safety precautions not recognizing the users initial click as a valid trigger for clicking the input. (On chromium browsers this isn’t even an issue). When the client wants to trigger the file selection, it uses Document.prototype.createElement, to create an input, and dispatches a click event on it. The interesting part about this is that it never adds the element to the DOM. Because the client uses an event listener waiting for the input to load the file, the current fix (that I think still works on image uploads for the player’s skin) is to just hijack the createElement function to directly add the element to the DOM. The click event still doesn’t trigger it, but the user can do it manually. It’s the not the prettiest solution, but it works (at least for the image inputs). Hopefully there is a better, less broken way to go about this.

[FlamedDogo99]

I just realized that the createElement function is indiscriminately grabbing any input element, which is a really dumb problem. This should be a fairly easy fix. I’ll correct it tomorrow.

[PlurrYT-Kolama]

i thought you used android? but yeah this is a really annoying bug

i mean yes but i mean it doesnt happens on android