Bug 249527 – Safari crashes on Twitter.com

• Status: NEW
• Component: Page Loading

Created attachment 464085 [details]
'This web page was reloaded because a problem occurred.‘ message.

Salutations,

Issue: Using twitter on iOS safari causes the following message to appear: 'This web page was reloaded because a problem occurred.‘ The steps to reliably replicate this crash isn’t available all that can be advised is to use Twitter regularly as you would the native app and witness whether your browser crashes. This has been an issue for ~3 updates. My iPhone is the 14 on iOS 16.1.2. It is likely this bug persists on iOS 16.2.

Attached is a video. 

Warm thoughts,

[Chris Dumez]

We need a crash log or a sysdiagnose to make this more actionable. You should be able to find the crash logs for the WebKit processes in the console app.

[Chris Dumez]

(In reply to Chris Dumez from comment #1)
> We need a crash log or a sysdiagnose to make this more actionable. You
> should be able to find the crash logs for the WebKit processes in the
> console app.

Oh this is iOS so I guess sysdiagnose would have to be the way to go, not the console app.

Salutations,

A aysdiagnose will be attached when the bug replicates. Does the sysdiagnose record the crash immediately or is there a period to wait before grabbing the sysdiagnose, e.g 5 minutes?

Warm thoughts,

(In reply to Chris Dumez from comment #2)
> (In reply to Chris Dumez from comment #1)
> > We need a crash log or a sysdiagnose to make this more actionable. You
> > should be able to find the crash logs for the WebKit processes in the
> > console app.
> 
> Oh this is iOS so I guess sysdiagnose would have to be the way to go, not
> the console app.

Salutations,

A aysdiagnose will be attached when the bug replicates. Does the sysdiagnose record the crash immediately or is there a period to wait before grabbing the sysdiagnose, e.g 5 minutes?

Warm thoughts,

*Replied directly as there is no way to delete comment of same message that's known to me.

[Alexey Proskuryakov]

It is best to collect a sysdiagnose immediately after an issue occurs. It would be best to create a new issue at https://feedbackassistant.apple.com and to attach it there, as the content of a sysdiagnose is somewhat privacy sensitive.

(In reply to Alexey Proskuryakov from comment #5)
> It is best to collect a sysdiagnose immediately after an issue occurs. It
> would be best to create a new issue at https://feedbackassistant.apple.com
> and to attach it there, as the content of a sysdiagnose is somewhat privacy
> sensitive.

The bug has been reported as of iOS 16 and the issue has not been remedied nor a follow up from a developer. It’s obnoxious and has the potential to induce epilepsy. Still with this potential in sudden motion to sensory stim-sensitive individuals Apple hasn’t fixed the issue. Reddit told me to report the bug here as bugs.webkit.org has influence on OS repairs.

[Chris Dumez]

(In reply to 02book-annular from comment #6)
> (In reply to Alexey Proskuryakov from comment #5)
> > It is best to collect a sysdiagnose immediately after an issue occurs. It
> > would be best to create a new issue at https://feedbackassistant.apple.com
> > and to attach it there, as the content of a sysdiagnose is somewhat privacy
> > sensitive.
> 
> The bug has been reported as of iOS 16 and the issue has not been remedied
> nor a follow up from a developer. It’s obnoxious and has the potential to
> induce epilepsy. Still with this potential in sudden motion to sensory
> stim-sensitive individuals Apple hasn’t fixed the issue. Reddit told me to
> report the bug here as bugs.webkit.org has influence on OS repairs.

Alexey is right that filing a feedback assistant issue is better when attaching a sysdiagnose, to protect your privacy. Once you have a feedback assistant number, you can post it here so we can follow-up.

[Radar WebKit Bug Importer]

<rdar://problem/103683064>

(In reply to Chris Dumez from comment #7)
> (In reply to 02book-annular from comment #6)
> > (In reply to Alexey Proskuryakov from comment #5)
> > > It is best to collect a sysdiagnose immediately after an issue occurs. It
> > > would be best to create a new issue at https://feedbackassistant.apple.com
> > > and to attach it there, as the content of a sysdiagnose is somewhat privacy
> > > sensitive.
> > 
> > The bug has been reported as of iOS 16 and the issue has not been remedied
> > nor a follow up from a developer. It’s obnoxious and has the potential to
> > induce epilepsy. Still with this potential in sudden motion to sensory
> > stim-sensitive individuals Apple hasn’t fixed the issue. Reddit told me to
> > report the bug here as bugs.webkit.org has influence on OS repairs.
> 
> Alexey is right that filing a feedback assistant issue is better when
> attaching a sysdiagnose, to protect your privacy. Once you have a feedback
> assistant number, you can post it here so we can follow-up.


Feedback assistant numbers: FB11887308, FB11888985, FB11890887, FB11892387, FB11893506, FB11895893. They will continue to be reported each and every time the bug occurs.

The bug occurred a couple minutes ago with a feedback assistant number of: FB11896063

[Alexey Proskuryakov]

rdar://103562616

Thank you, we will take a look.

(In reply to Alexey Proskuryakov from comment #11)
> rdar://103562616
> 
> Thank you, we will take a look.

Any updates on fixes? This was reported again with case number: FB11974151 today. The problem persists on iOS 16.3

Kind thoughts.

[Ben Nham]

This webpage is dying because the WebContent process it's running in hit a memory limit (X GB, varies by device). From looking at the logging emitted when the process hits the warning threshold limit, almost all of this memory is attributed to the JS heap:

```
WebKit memory usage statistics at time of warning memory pressure notification:
javascript_gc_heap_capacity_mb: 963
phys_footprint_mb: 1183
...
```

While it's possible that this is due to a WebKit bug, it's more likely to be a bug in the website itself. I'll try to use the Twitter web app to see if I see OOM crashes on it on my own device. But unless that uncovers an actual WebKit bug (e.g. use of some web feature that creates a document leak), this will have to be fixed by the website, not WebKit.

(In reply to Ben Nham from comment #13)
> This webpage is dying because the WebContent process it's running in hit a
> memory limit (X GB, varies by device). From looking at the logging emitted
> when the process hits the warning threshold limit, almost all of this memory
> is attributed to the JS heap:
> 
> ```
> WebKit memory usage statistics at time of warning memory pressure
> notification:
> javascript_gc_heap_capacity_mb: 963
> phys_footprint_mb: 1183
> ...
> ```
> 
> While it's possible that this is due to a WebKit bug, it's more likely to be
> a bug in the website itself. I'll try to use the Twitter web app to see if I
> see OOM crashes on it on my own device. But unless that uncovers an actual
> WebKit bug (e.g. use of some web feature that creates a document leak), this
> will have to be fixed by the website, not WebKit.

My iPhone has 6 GB of RAM, it’s the regular iPhone 14 which clearly doesn’t have enough memory to handle twitter unfortunately. This replicates only on Twitter alluding to your notion that Twitter is the root of the problem. A case will be opened with twitter to simultaneously diagnose and solution provide. 

Appreciate your germane reply! Keep me up to date if you can/want!

[Ben Nham]

Note that the web page can't use all 6GB of RAM on your device. The OS sets a lower memory limit on individual processes for many reasons (e.g. to make multitasking work well). But the amount of memory afforded to a webpage is still significant--it's much more than a gigabyte.