NUI files fail to load

FiveM Discussion Bug Reports
1

1.) Bug is experienced on Beta and Latest (Unstable) client builds, it is not experienced on current Release build. FXServer unchanged during testing, currently on latest recommended 5848.
2.) What is expected to happen and what does happen on the Release client build is the scratch card UI comes up and allows the players to scratch the card. Having added console logs, the logs are expected to appear on resource start as the .js file initializes.
3.) What actually happens is the .lua file calls SetNUIFocus, soft-locking Beta and Latest (Unstable) client build players in a non-functional UI screen with just the mouse cursor. Upon resource start, no console logs from the .js file are produced in the client f8 console as they are on the Release build.
4.) Category of bug: Client/NUI
5.) Reproduction steps for soft-locking:
Install and run GitHub - xDreamLand/dr-scratching: FiveM - Scratching Card Resource [ESX]
Call the client event “dr-scratching:nuiOpenCard”, easily achieved if running es_extended and using the item provided
If on Release build, you will receive the proper UI page, being allowed to scratch your card, if you are on Beta or Latest (Unstable) build you will become soft-locked with no UI provided.

I am not sure if these images will embed properly but following is images of the Beta build having the resource restarted, the Release build having the resource restarted, the expected (and Release build) outcome of calling to the UI, the bug (and Beta/Latest) outcome of calling to the UI, and the server version verification.

Edit, post screenshot taking I noticed the cursor is not visible in the final screenshot of the no UI, sorry





2

Do you have any reproduction case that does not require ‘es_extended’ or other convoluted setup?

3

I have created a repository with a stripped down copy of the resource that only uses a command and calls the UI

4

It should now be download, install, and run the above copy of the resource. Once in server call the forcescratcher command

5

Removing the lua54 property did not affect the issue at all.

6

I can verify this was tested on another server as well now, my localhost provides the same issue as the live server the issue was originally discovered on. On Release the system functions as desired, Beta or Latest and it fails to show any UI or seemingly load the card.js file at all. I haven’t noticed any other resources failing in the same manner so I am apt to believe it is something very specific. I have noticed the system does not use escrow but does call lua54 so I will next attempt removing the lua54 property and testing and report back once available.

7

I haven’t gotten a chance to check yet, but might loading two instances of ‘jquery’ be the issue? One thing that changed since the last production release is that Chromium was bumped from 91 to 103, and that could behave differently like that.

8

Issue seems to arise when using . (dots) in the resource name, uncertain if this is correct (web browser) behavior. Until further decision, you can remove or replace the dots in your resource name and it should work again.

9

https://cfx-nui-dr-scratching-3.1.0/ does seem to be an invalid URL according to current versions of Chrome, indeed - likely related to the numbers in the last part of the hostname. This might be a bit difficult to resolve as it’d run counter to API expectations that resource names can be used in URLs directly. :confused:

10

Deduced it to Chromium commit f21b724918b277919a898464926568d79d595016, claiming ‘the URL spec has been updated to parse any hostname ending with a numeric component as IPv4 unconditionally’. This is nasty, since this leads to a compat break even if we escape the resource name in the URL, since currently 'https://cfx-nui-' + resourceName is a common way to get a resource base URL (see even topics posted this week such as How we solved the third party app problem for NPWD, and how you can use the same approach).

I truly love ‘web standards’ people… :roll_eyes:

11

From an internal context regarding this:

Possible strategies:

  1. revert Chromium commit: problematic (huge commit), effort, will make future upgrades more difficult. most viable option though, sigh.
  2. ‘just accept it being broken’: impossible, lots of resources that are downloaded from GH like this :confused: even informing users won’t work
  3. work around it by removing weird chars from resource name in NUI on client-side: would break concatenation
  4. work around it by removing weird chars from resource name on client side in general: would break weird ‘anticheat scripts’
  5. work around it by removing weird chars from resource name server side: would require a server update to not break, and could still confuse users/code/… that assume resource names aren’t canonicalized :confused:
12

I’m not sure if it’s viable as I don’t know too much about the web end of things, but instead of removing characters, would appending an extra character break concatenation in NUI client-side? Also, I appreciate the effort and responses a ton

13

It’d have similar concerns of the resource name not matching anymore, yes.

14

Fixed via fix(vendor): update CEF to cfx-m103.2604 ¡ citizenfx/fivem@fce2541 ¡ GitHub applying [Cfx] Revert incompatible URL parsing changes ¡ citizenfx/chromium@1dd9a14 ¡ GitHub.

1 Like