More drama? What I posted above is factual and true.
Fixed PageSpeed Insights & 2.2
- Thread starter Anatoliy
- Start date
Anatoliy
Well-known member
I agree. PageSpeed Insights doesn't read xF 2.2 because of covid. It's factual and true.
Anatoliy
Well-known member
I will. As soon as you explain me why you decided that you can speak on behalf of everyone.Stop wasting everyone's time, please.
@sy509 and @XenArabia have discovered that if you remove
This mostly confirms what we already knew - this is an internal issue to Lighthouse. I have tried keeping the
It's also worth noting that this is not new in XF 2.2. This same attribute was there with the same value in XF 2.1 and XF 2.0 but clearly some code path in their tool related to PWA support is now causing it to trip over.
We will attempt to report this to them via the existing issue on GitHub.
data-app="public" from the PAGE_CONTAINER template then you no longer get the "internal error".This mostly confirms what we already knew - this is an internal issue to Lighthouse. I have tried keeping the
data-app attribute, but setting it to a different value. Any value except public works. Including, publi or pub or not-public.It's also worth noting that this is not new in XF 2.2. This same attribute was there with the same value in XF 2.1 and XF 2.0 but clearly some code path in their tool related to PWA support is now causing it to trip over.
We will attempt to report this to them via the existing issue on GitHub.
Anatoliy
Well-known member
taking back this one. checked with an old browser. it's just a duplicating notice. I thought that error message is all that a crawler can see.
so I replace "will disappear from SERP" with "will drop down in SERPs" as G can't afford to show links with low CTR.
Okay thanks to @Jeremy P's efforts in tracking this down we now have a workaround in place for this and have been able to shed some light on the situation.
The reason changing
Inexplicably, it turns out that the root cause of this issue is in fact a bug in "headless Chromium" which causes it to crash when it accesses the Notification.badge API.
This existing bug has been reported here:
We will attempt to give them a nudge but from an XF point of view it is fixed. We now detect if the user agent appears to be from Lighthouse and bypass that API in that case.
Those changes are rolled out here if you'd like to test them.
The reason changing
data-app="public" to any other value works is because there are some relevant PWA bits that only run if that value is set to public.Inexplicably, it turns out that the root cause of this issue is in fact a bug in "headless Chromium" which causes it to crash when it accesses the Notification.badge API.
This existing bug has been reported here:
We will attempt to give them a nudge but from an XF point of view it is fixed. We now detect if the user agent appears to be from Lighthouse and bypass that API in that case.
Those changes are rolled out here if you'd like to test them.
Last edited:
eva2000
Well-known member
excellent news !
Anatoliy
Well-known member
is it time for xF 2.2.0 Beta1 Patch1?
did this make it into the release? just upgraded to 2.2 and lighthouse crashes.Okay thanks to @Jeremy P's efforts in tracking this down we now have a workaround in place for this and have been able to shed some light on the situation.
The reason changingdata-app="public"to any other value works is because there are some relevant PWA bits that only run if that value is set topublic.
Inexplicably, it turns out that the root cause of this issue is in fact a bug in "headless Chromium" which causes it to crash when it accesses the Notification.badge API.
This existing bug has been reported here:
We will attempt to give them a nudge but from an XF point of view it is fixed. We now detect if the user agent appears to be from Lighthouse and bypass that API in that case.
Those changes are rolled out here if you'd like to test them.
Similar threads
- Question
