Mintplex-Labs/anything-llm
1
0
Fork 0
mirror of https://github.com/Mintplex-Labs/anything-llm.git synced 2026-07-19 22:23:50 -04:00
Code Issues 328 Packages Projects Releases 10 Wiki Activity

[GH-ISSUE #5055] [BUG]: request desktop ignored on mobile #4890

New Issue
Closed
opened 2026-06-05 14:50:42 -04:00 by yindo · 5 comments
yindo commented 2026-06-05 14:50:42 -04:00
Owner
Copy Link
Copy Source

Originally created by @elevatingcreativity on GitHub (Feb 23, 2026).
Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5055

How are you running AnythingLLM?

Docker (local)

What happened?

The default for AnythingLLM on Docker seems to be to prevent adjusting configuration settings and file uploads for a workspace when on mobile, including tablets.
Setting “request desktop” is ignored, so no settings can be adjusted, even on a larger screen mobile device.
The screenshots show that desktop has been selected, but the blocking modal is still shown.
This prevents usage on a variety of devices.

Image
Image

Are there known steps to reproduce?

  1. use a mobile device like ipad
  2. create a workspace
  3. try to open up file uploading
  4. receive dialog saying one must be on desktop
  5. switch setting to “request desktop” in browser (eg Safari)
  6. try to open up file uploading again
  7. get the same blocking message
Originally created by @elevatingcreativity on GitHub (Feb 23, 2026). Original GitHub issue: https://github.com/Mintplex-Labs/anything-llm/issues/5055 ### How are you running AnythingLLM? Docker (local) ### What happened? The default for AnythingLLM on Docker seems to be to prevent adjusting configuration settings and file uploads for a workspace when on mobile, including tablets. Setting “request desktop” is ignored, so no settings can be adjusted, even on a larger screen mobile device. The screenshots show that desktop has been selected, but the blocking modal is still shown. This prevents usage on a variety of devices. ![Image](https://github.com/user-attachments/assets/e49f0b7a-f903-44b3-9e72-a758045c35fb) ![Image](https://github.com/user-attachments/assets/a2996d20-b396-4153-9134-d11b10ff77e5) ### Are there known steps to reproduce? 1. use a mobile device like ipad 2. create a workspace 3. try to open up file uploading 4. receive dialog saying one must be on desktop 5. switch setting to “request desktop” in browser (eg Safari) 6. try to open up file uploading again 7. get the same blocking message
yindo added the possible bug label 2026-06-05 14:50:42 -04:00
yindo closed this issue 2026-06-05 14:50:42 -04:00
yindo commented 2026-06-05 14:50:43 -04:00
Author
Owner
Copy Link
Copy Source

@shatfield4 commented on GitHub (Feb 24, 2026):

Closing due to how we use isMobile from react-device-detect.

We also do not have UI elements that can properly render all information even on iPad/tablet sized devices for the file uploading modal which is why we block this from displaying.

<!-- gh-comment-id:3953626747 --> @shatfield4 commented on GitHub (Feb 24, 2026): Closing due to how we use `isMobile` from `react-device-detect`. We also do not have UI elements that can properly render all information even on iPad/tablet sized devices for the file uploading modal which is why we block this from displaying.
yindo commented 2026-06-05 14:50:43 -04:00
Author
Owner
Copy Link
Copy Source

@elevatingcreativity commented on GitHub (Feb 24, 2026):

@shatfield4
Ok. The upload modal is ~560px wide. Even the iPad mini can do this, much less the 13" M3 Pro.
React is very problematic in this regard. I (and many others) have all sorts of problems with Notion on iPads, because of this. What is possible is limited on mobile, and yet there is almost no way to use a web browser in desktop mode. Given that the effective screen is 1024 x 1366 pixels, many like me often use these as a lightweight laptop replacement, but then run into needless restrictions like this.
The fix is easy, I am testing it locally: just have the limit be based on available pixel size of screen, not the react-device-detect.
Why make it hard on users?
I will submit a PR when done with testing.

<!-- gh-comment-id:3954876760 --> @elevatingcreativity commented on GitHub (Feb 24, 2026): @shatfield4 Ok. The upload modal is ~560px wide. Even the iPad mini can do this, much less the 13" M3 Pro. React is very problematic in this regard. I (and many others) have all sorts of problems with Notion on iPads, because of this. What is possible is limited on mobile, and yet there is almost no way to use a web browser in desktop mode. Given that the effective screen is 1024 x 1366 pixels, many like me often use these as a lightweight laptop replacement, but then run into needless restrictions like this. The fix is easy, I am testing it locally: just have the limit be based on available pixel size of screen, not the react-device-detect. Why make it hard on users? I will submit a PR when done with testing.
yindo commented 2026-06-05 14:50:43 -04:00
Author
Owner
Copy Link
Copy Source

@elevatingcreativity commented on GitHub (Mar 3, 2026):

Update: Fix implemented in PR #5132

After investigating, the root cause is that isMobile from react-device-detect uses the user agent string to detect mobile devices. On iPadOS 13+, Safari already sends a
macOS desktop user agent by default, yet the library still classified it as mobile through other heuristics. More importantly, even when "Request Desktop Site" is
explicitly enabled, the detection remained unreliable across browsers because signals like navigator.maxTouchPoints reflect hardware capability and never change
regardless of browser mode. This same problem would affect Android tablets and other large-screen touch devices for the same reasons.

The fix uses actual viewport dimensions instead of user agent detection:

  • The blocking condition was changed from isMobile to window.innerWidth < 560 || window.innerHeight < 600
    • < 560px wide blocks phones in portrait — this is the actual minimum width the modal needs to render
    • < 600px tall blocks phones in landscape — phone landscape heights max out around 430px, while tablets in landscape are typically 740px+, so this threshold cleanly
      separates the two categories regardless of manufacturer or OS
  • md:overflow-y-auto on the modal container was changed to overflow-y-auto — tablets in portrait can fall below Tailwind's 768px md breakpoint, which was silently
    disabling scroll in that configuration
  • An onTouchEnd handler was added to the upload button in the sidebar to fix a double-tap issue on iOS — the button is a descendant of an element, which causes iOS
    Safari to activate hover state on first tap and fire click only on the second tap. This may affect other touch browsers with similar hover simulation behavior.
  • The blocking message was updated to describe the actual constraint (screen width) rather than incorrectly saying "desktop only"

I only had iPhone and iPad devices available for testing (screenshots below show iPhone blocked correctly, iPad mini accessible and scrollable in both orientations, and
iPad Pro with trackpad behaving identically to desktop). The fix should benefit Android tablets and other large-screen touch devices as well, though I wasn't able to
verify those directly.

iPad Pro - large Tablet Screen

Image

iPad mini Screen

Image

Phone - updated blocking message:

Image

@shatfield4 let me know if you would like any other changes to consider pulling this. I looked at doing unit tests, but couldn't figure out how to incorporate those, and there doesn't seem to be a codebase for UI/UX changes.

<!-- gh-comment-id:3994967790 --> @elevatingcreativity commented on GitHub (Mar 3, 2026): ### Update: Fix implemented in PR #5132 After investigating, the root cause is that isMobile from react-device-detect uses the user agent string to detect mobile devices. On iPadOS 13+, Safari already sends a macOS desktop user agent by default, yet the library still classified it as mobile through other heuristics. More importantly, even when "Request Desktop Site" is explicitly enabled, the detection remained unreliable across browsers because signals like navigator.maxTouchPoints reflect hardware capability and never change regardless of browser mode. This same problem would affect Android tablets and other large-screen touch devices for the same reasons. The fix uses actual viewport dimensions instead of user agent detection: - The blocking condition was changed from isMobile to window.innerWidth < 560 || window.innerHeight < 600 - < 560px wide blocks phones in portrait — this is the actual minimum width the modal needs to render - < 600px tall blocks phones in landscape — phone landscape heights max out around 430px, while tablets in landscape are typically 740px+, so this threshold cleanly separates the two categories regardless of manufacturer or OS - md:overflow-y-auto on the modal container was changed to overflow-y-auto — tablets in portrait can fall below Tailwind's 768px md breakpoint, which was silently disabling scroll in that configuration - An onTouchEnd handler was added to the upload button in the sidebar to fix a double-tap issue on iOS — the button is a descendant of an <a> element, which causes iOS Safari to activate hover state on first tap and fire click only on the second tap. This may affect other touch browsers with similar hover simulation behavior. - The blocking message was updated to describe the actual constraint (screen width) rather than incorrectly saying "desktop only" I only had iPhone and iPad devices available for testing (screenshots below show iPhone blocked correctly, iPad mini accessible and scrollable in both orientations, and iPad Pro with trackpad behaving identically to desktop). The fix should benefit Android tablets and other large-screen touch devices as well, though I wasn't able to verify those directly. ### iPad Pro - large Tablet Screen <img width="2752" height="2064" alt="Image" src="https://github.com/user-attachments/assets/fae16237-bd80-4c1b-91be-f2211f74fc80" /> ### iPad mini Screen <img width="2266" height="1488" alt="Image" src="https://github.com/user-attachments/assets/16df8d9b-c4bf-4824-9c69-66252026da98" /> ### Phone - updated blocking message: <img width="1206" height="2622" alt="Image" src="https://github.com/user-attachments/assets/980d6cfd-efe3-4873-b8e7-6ca20c746756" /> @shatfield4 let me know if you would like any other changes to consider pulling this. I looked at doing unit tests, but couldn't figure out how to incorporate those, and there doesn't seem to be a codebase for UI/UX changes.
yindo commented 2026-06-05 14:50:43 -04:00
Author
Owner
Copy Link
Copy Source

@elevatingcreativity commented on GitHub (Mar 5, 2026):

@timothycarambat also pinging you on this submitted fix. This may fall under the category of "enhancement" rather than "bug fix," nonetheless I'm finding it quite useful in my own fork.

<!-- gh-comment-id:4008008181 --> @elevatingcreativity commented on GitHub (Mar 5, 2026): @timothycarambat also pinging you on this submitted fix. This may fall under the category of "enhancement" rather than "bug fix," nonetheless I'm finding it quite useful in my own fork.
yindo commented 2026-06-05 14:50:43 -04:00
Author
Owner
Copy Link
Copy Source

@timothycarambat commented on GitHub (Mar 5, 2026):

Yeah, we just need to get the mobile designs for those components, however the interim modal change makes more sense that what we currently have just because the reason you cannot access it is quite vague when its purely screen-size related.

However, that is an annoying quirk that isMobile is not detecting IPad sizes 🤔

<!-- gh-comment-id:4008101743 --> @timothycarambat commented on GitHub (Mar 5, 2026): Yeah, we just need to get the mobile designs for those components, however the interim modal change makes more sense that what we currently have just because the reason you cannot access it is quite vague when its purely screen-size related. However, that is an annoying quirk that isMobile is not detecting IPad sizes 🤔
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Desktop
Docker
Integration Request
Integration Request
OS: Linux
OS: Mobile
OS: Windows
UI/UX
blocked
bug
bug
core-team-only
documentation
duplicate
embed-widget
enhancement
feature request
github_actions
good first issue
investigating
needs info / can't replicate
possible bug
pull-request
Mirrored from GitHub Pull Request
 question
stage: specifications
wontfix
No Label possible bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Mintplex-Labs/anything-llm#4890
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?