[Bug]: Apps UI not working in WebKit browsers (Safari, iOS/iPadOS, GNOME/Epiphany)

[BJKle]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

When selection any app in the "your apps" "active apps" "disabled apps" section always the same app will be displayed. E.g. selection "Activity" -> "Versions" is displayed. Scrolling doesn't work as well.

Steps to reproduce

1. Open Apps
2. Select an app to manipulate
3. in my case "Versions" is displayed

Expected behavior

The selected app should be displayed to enable/disable

Installation method

None

Nextcloud Server version

28

Operating system

Debian/Ubuntu

PHP engine version

PHP 8.2

Web server

Nginx

Database engine version

MariaDB

Is this bug present after an update or on a fresh install?

Upgraded to a MAJOR version (ex. 22 to 23)

Are you using the Nextcloud Server Encryption module?

Encryption is Disabled

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[joshtrichards]

Hi @BJKle - I'm unable to reproduce this behavior. Can you try a different browser and/or device and/or disable extensions like ad blockers?

If it persists after that, please share what browser(s) and OSes you're seeing this behavior on. Thanks!

[tiptoptrash]

Hi @joshtrichards: I have the same problem.
Using Safari on macOS Sonoma, iOS 14.2 and iPadOS 14.2, the problem ist present.
Using Firefox on macOS Sonoma, the problem is not reproducible.

Affected are the list under "Your apps", "Active apps", "Disabled apps", "App bundles" and "Feautured apps". All those lists are static and cannot be scrolled.
The other items starting with "Customization" behave totally normal.

I hope, that helps, thanks a lot!

[BJKle]

@joshtrichards
I can't test another browser. Only safari is allowed on my system (macOS 14.2/M1). All others are blocked by admin.

Edit:
@joshtrichards I tried it on someone else PC scrolling and selecting is working on Chrome. It seems to be a Safari specific Problem. I have Safari 17.2.1.

[derrickpeavy]

Can affirm:

Using Safari on macOS Monterey (12.7.1), Safari 17.1, the problem is present.
Using Firefox on macOS Monterey (12.7.1), no problems.

This problem IS still present in NextCloud 28.0.1.

Pretty sure this is a CSS change that was introduced with 28.0.0.11, the list of apps will not scroll and clicking to enable or disable any app simply brings up an info panel on some other app which was not clicked.

[BJKle]

I tried different browsers (FF/Edge) on iOS/iPadOS and is not working as well.
This really needs to get fixed.

[joshtrichards]

Reproduced successfully in GNOME Web (Epiphany) [V43 as distributed with Debian bookworm], which is also WebKit based just like all reported browser scenarios so far.

[cloudguy23]

I'll add that Forms app is also affected. I'm able to create forms, complete, and share forms via Safari. However, a user will encounter an error - "There was an error submitting the form" - when submitting a form that was shared with them via Safari. Chrome, Brave, Firefox all work without issue.

[eweinhold]

Nextcloud 28.0.2 RC3 still not scrolling on safari :(

That not scrolling Bug persists in Nextcloud 28.0.2 RC3.

All Safari Browsers on all systems are affected Desktop, iPad, iPhone.
Last Version and just updated current version 17.3 iOS and 14.3 macOS

[eweinhold]

Nextcloud 28.0.2 RC3 still not scrolling on safari :(

That not scrolling Bug persists in Nextcloud 28.0.2 RC3.

All Safari Browsers on all systems are affected Desktop, iPad, iPhone. Last Version and just updated current version 17.3 iOS and 14.3 macOS

Nextcloud 28.0.2 RC4 still not scrolling :(

affected views:
/index.php/settings/apps
settings/apps/enabled
settings/apps/disabled
settings/apps/app-bundles
settings/apps/featured
settings/apps/search

the other apps views / preview Lists are not affected. they do scroll.

[gcoretech]

As an example see: /settings/apps/installed/calendar
That page is divided into three sections: the category on the left, the app list in the middle and the details of the selected app on the right.

The page seems to be generated by:
https://github.com/nextcloud/server/blob/master/apps/settings/src/components/AppList/AppItem.vue

The following style is defined at the bottom of AppItem.vue:

.app-name--link::after {
  content: '';
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
}

If you add background-color: yellow to that, the whole app list is yellow. Set content: 'X' and change position to relative, you will see just an X with yellow background right after every app name. The whole list is not yellow anymore and it's scrollable again.

I cannot fully test this because /apps/settings/src/components/AppList/AppItem.vue is not available on my nextcloud server. It seems to be added with webpack so it's not easy for me to test it.

Perhaps someone could try to remove .app-name--link::after from AppItem.vue and see if that fixes it.

[mhzawadi]

So I have this issue and have gone to test editing the /apps/settings/src/components/AppList/AppItem.vue file, but I dont have it on my server. My apps/settings/ is missing the src directory

Is that the issue that the file is missing?

[mhzawadi]

also the community zip file is missing the /apps/settings/src directory

[gcoretech]

@mhzawadi A nextcloud developer should have a look at this as those files are not part of a regular nextcloud installation. The code these files produce is seemingly packed/minified into javascript files that your nextcloud installation uses but it's hard to edit them directly because of the minification.

[mhzawadi]

Hey @gcoretech

I have the docker dev environment setup and working, I have edited .app-name--link::after to have yellow and can see it in Opera. But Safari is not yellow and still doesn't scroll.

[gcoretech]

Hey @mhzawadi
background-color: yellow visualizes which area is affected in safari, scrolling works after changing position: absolute to position: relative.

This is from Safari developer tools (position changed to relative):

All apps in the app list now have an X with a red border and yellow background right after the app name and scrolling works:

Changing position back to absolute the whole app list is yellow and all the apps are behind the yellow pane so you can't see them. Imagine the picture above all yellow, without any text.

Hope this helps.

[mhzawadi]

can confirm that removing position: absolute; allows the table to scroll

[tallinn1960]

As this issue only mentions scrolling, I would like to add that app selection in the active app list is broken as well on macOS 14.4/Safari 17.4 in NC 28.0.3. On my system, the browser selects the last app in the list (in my case, the weather app) and sticks with it, no matter what app one is clicking on.

[derrickpeavy]

As this issue only mentions scrolling, I would like to add that app selection in the active app list is broken as well on macOS 14.4/Safari 17.4 in NC 28.0.3. On my system, the browser selects the last app in the list (in my case, the weather app) and sticks with it, no matter what app one is clicking on.

THAT IS CORRECT FOR ME AS WELL!

[ShGKme]

The issue is caused by Safari not applying position: relative on <tr>
See: https://bugs.webkit.org/show_bug.cgi?id=240961

Both issues: broken scrolling and opening an app in the sidebar.

Removing position: absolute fixes the issue, but it removed the ability to click on the row to open app in the sidebar, making only the text of app name clickable.

#44236 should with both issues keeping row clickable.

[darthmarx]

Not fixed in 28.0.4

[joshtrichards]

It's fixed in v29. It's going to require some manual intervention to finalize the backport for v28 it looks like (pending in #44327).

[nicnab]

Thanks for keeping us in the loop, @darthmarx and @joshtrichards !

[mehlkopf]

It's still not fixed in 28.0.5. Honestly, it is a great symptom of what is wrong with Nextcloud's fast update release cycle: either I am supposed to stay longer on the older versions, but then all bugs should be fixed first on these versions, OR I should always update and can assume the latest versions to be the most reliable, but that is obviously also not the case. It is really frustrating.

[nicnab]

Are you sure it isn't? This post says it is. I will try to test myself before upgrading my customer's instance but I first have to find a Safari to test on.

[mehlkopf]

Unfortunately, for me, it is not fixed as of 28.0.5.
UPDATE: The post you are referring to is relating to different Safari-specific bug!

[nicnab]

Oh I'm sorry. Reading skills sometimes do help. As I will be the only one dealing with apps it iis not a problem for me at the moment but I understand it is for you.

[joshtrichards]

It's fixed in v29, but the backport requires extra manual intervention: #44327

[joshtrichards]

Honestly, it is a great symptom of what is wrong with Nextcloud's fast update release cycle: either I am supposed to stay longer on the older versions, but then all bugs should be fixed first on these versions, OR I should always update and can assume the latest versions to be the most reliable, but that is obviously also not the case.

It sounds like your requirements might justify always sticking with the last supported stable, which is always the most field proven. At present that would be v27. And at the time of this bug report, that was v26. Neither were impacted by this bug. So the bug wasn't even present for those choosing the most field tested (i.e. not the latest major) for their production environments.

Briefly, we actively support (generally) three majors at a given point in time:

• latest stable
• previous stable
• last supported stable

We recently (in the last couple months) tried to clarify and better document this so that admins can make their own decisions based on what is most important in their environments: https://docs.nextcloud.com/server/latest/admin_manual/release_schedule.html

Either way, yes, this bug fix backport needs to get done in an upcoming v28 maintenance release. But there are only so many hours in the day. You're also always welcome to test/review/modify the proposed backport to nudge it forward. Or pay Nextcloud GmbH (or someone) to do so.

P.S. For the record, this is a WebKit / Apple bug we're working around (that was reported ~2 years ago): https://bugs.webkit.org/show_bug.cgi?id=240961 But, yes, we need to workaround it to provide a good user experience until resolved there.

[ShGKme]

Sorry, will be backported to v28 before the next minor release.

[mehlkopf]

@joshtrichards Thank you for your reply! First and foremost, I am very thankful for all the work you are doing, and it is good to have these clarifications regarding update strategies.
Nevertheless, I think the version 28 cycle has been very rough for lots of people, and I think it should result not only in clarification of these update strategies, but also regarding testing procedures and release schedules. This app screen bug is a very minor annoyance in comparison to lots of bugs introduced in 28.0, which were thankfully gradually improved on in the .0.x versions. However, I personally think 28.0.0 should never have been released in this state, there were way too many bugs that simple testing routines (like drag and drop a file into the browser, try to move/duplicate files, overwriting files at upload, not handling new file creation properly, etc., all these things were not working in v28) could have prevented. And in the same vain, a simple test of all screens (scrollable? clickable?) in different browser would have prevented this app list bug from shipping (at least unknowingly).
For me, it was the first time in years I had more than 1-2 minor issues when running a new version. So, in my opinion, something fundamentally went wrong and it would be great to see the development process learning from that – because it also cannot be the goal to just allow the most hobbyist users to use the most recent version. So overall, I think development on new things should slow down and testing should be more rigorously at least such that new .0 versions will be as stable as the other 20s version were.
And I know there are lots of people working with constrained resources, so I am very thankful for all your work – I am just not certain the resources are always appropriately assigned to new developments vs. reliability/bug fixing.