Bug 295625 – REGRESSION (iOS 26): Performance issues on dendionigi.com

• Component: Layout and Rendering
• Status: RESOLVED DUPLICATE

I am testing stuff on a website, and it worked well on any mobile browser till iOS18.

Now that I am testing iOS26, even with the latest BETA (3) everything works smoothly on any other mobile browser but Safari.
Safari iOS26 crashes and lag, while the same web screens, side by side, with another iPhone, same model but running iOS18, don't give any issue.

Previously I had also the bug for status-bar flickering and lagging, which now has been patched, but instead the popovers and pages bugs seem still there.

SITUATION:

I have persistent popovers and ajax smooth navigation, and both are rendering with bugs, lagging and fouc while views/pages change.

Example: If I have an element which must stay on its place and its width is 100vw: while pages change: it blinks, shrinks, flicker and jumps on rendering, instead it simply must stay as is..

Animations and page transitions work smoothly on Chrome mobile (latest iOS 26 beta 3) , so it's something just related to Safari and webkit.

I did open an Apple Feedback FB18328720, but seems no one caring.

You can see here a video of the issue: https://www.youtube.com/shorts/rY3oxUwDd7w

And here you can test live: opening the bottom sheet, you can see bottom links, which should be persistent across page views without any crazy lag or shrinks, which is visible only on latest iOS26 mobile Safari browser: https://www.youtube.com/shorts/rY3oxUwDd7w

It's a rendering engine issue.

Forgot a demo link: https://dendionigi.com/

And, to give a comparison, I post also the Chrome mobile view, which is clearly smoother and fluid.

Maybe something related to native CSS @view-transition {navigation: auto} , view-timelines and scroll-timelines and popovers top layers?

Created attachment 475823 [details]
video of iOS 26 Chrome views

What Chrome gives.

[Brent Fulgham]

Since Chrome on iOS is the same engine, this is likely the site being confused by the new OS or Safari version.

[Brent Fulgham]

To Clarify: Did you mean that iOS 18 also experienced problems? Or are you stating that the problem started with iOS 26?

If you have a Mac and can use WebInspector on that site, you can change Safari to use the iOS 18.5 User Agent. I'd be very interested to know if your problems go away when the UA changes back to the earlier version.

Hi all,
seems a huge faulty issue was CSS filter blur transitions.
But the problem is that before any iOS26 beta, I dint see any of this issue.

I got 2 iPhones, same model, 2 iOS versioning and the two work differently only while using Safari.

And even crazier: the one which has been updated to iOS 26 beta has different behaviour between browsers.

I have tested with:

Chrome mobile
Brave mobile
Tor mobile

and of course: Safari.

Safari on iOS26 is the only one which has those hufe visual bugs.


Even if the issues are still there, I skipped the problem trying a combo of solutions:


1) view transitions on [popover] = before I had simply a view-transition name="foo" with no animation/transition set , not I brutally added an "animation:none" which now patches the popover rendering issue.

But, going back to what I said earlier.. this is an unecessary step, at least not required on iOS18 (on my own opinion).

2) I changed view-transitions, removing any CSS filter animation and switched with a basic CSS view transition with slide-x between views.

_________________


But crazy: still have rendering issue only on Safari.

Now:

on Chrome pages smoothly slide between each other, of Safari there's a huge fouc. Only on Safari mobile, because on macOS with Tahoe... this problem ain't present at all. 


You can see a video here, where navigation is under incognito mode for both browsers (iOS26): https://youtube.com/shorts/BzXTaKINpwA

white: Safari
black: Chrome

[Alexey Proskuryakov]

*** Bug 295624 has been marked as a duplicate of this bug. ***

[Alexey Proskuryakov]

rdar://154168198

[Tim Nguyen (:ntim)]

This was fixed in bug 296107

*** This bug has been marked as a duplicate of bug 296107 ***