Topic on Extension talk:Header Tabs

Header Tabs sometime fails to load

22
Jongfeli (talkcontribs)

Ever since we upgraded to MW1.35 it sometimes happens that opening a page that uses multiple headers fails to load properly.

Everything is on the page and the tabs are also on top but all the page content is shown below the first header. The tabs do not work.

When you go back one page and click on the link again or use F5 the page loads normally and after that it seems to keep working until time X has passed.

I get the fault Exception in module-execute in module ext.headertabs (see screenshot) and I tried to figure out what is going on but I am not sure where to look first.

Can someone please push me in the right direction :-)

Yaron Koren (talkcontribs)

Nice work getting that screenshot ready for public viewing! Are you using the latest version of Header Tabs? Also, I would recommend adding "?debug=true" (or "&debug=true") to the URL, then reloading until the error happens - the error message in the console may be more helpful.

Jongfeli (talkcontribs)

Well it is not up to me, it is our company wiki :-)

I tried lots of times with the links and adding ?debug=true but it does not want to fail.

Then it happened when using &action=purge. On some pages we use a link with &action=purge to force a Sematic update.

The below code was in de Console, maybe this helps. I will try tomorrow with the debug option and dig some more.

POSThttp://internalwiki.blabla.com/internalwiki/index.php?title=Somepage&action=purge
[HTTP/1.1 302 Found 1227ms]

GEThttp://internalwiki.blabla.com/wiki/Somepage
[HTTP/1.1 200 OK 6804ms]

This page uses the non standard property “zoom”. Consider using calc() in the relevant property values, or using “transform” along with “transform-origin: 0 0”. Somepage
GEThttp://internalwiki.blabla.com/internalwiki/load.php?lang=en&modules=startup&only=scripts&raw=1&skin=vector
[HTTP/1.1 200 OK 0ms]

GEThttp://internalwiki.blabla.com/internalwiki/load.php?lang=en&modules=ext.jquery.async%7Cext.libs.tippy%7Cext.smw%7Cext.smw.purge%2Ctooltips%7Csmw.entityexaminer%2Ctippy&skin=vector&version=1gv35
[HTTP/1.1 200 OK 0ms]

GEThttp://internalwiki.blabla.com/internalwiki/load.php?lang=en&modules=ext.headertabs%7Cext.pageforms.autoedit%7Cjquery%2Coojs%2Coojs-ui-core%2Coojs-ui-widgets%2Coojs-ui-windows%2Csite%7Cjquery.client%2CmakeCollapsible%2Ctablesorter%7Cmediawiki.String%2CTitle%2Capi%2Cbase%2Ccldr%2CjqueryMsg%2Clanguage%2Cutil%7Cmediawiki.language.months%7Cmediawiki.libs.pluralruleparser%7Cmediawiki.page.ready%2Cstartup%7Cmediawiki.page.watch.ajax%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui-widgets.icons%7Coojs-ui-windows.icons%7Coojs-ui.styles.indicators%7Cskins.vector.legacy.js%7Cuser.defaults&skin=vector&version=1yorw
[HTTP/1.1 200 OK 0ms]

JQMIGRATE: Migrate is installed with logging active, version 3.1.0 load.php:147:171
Exception in module-execute in module ext.headertabs: load.php:2:530
TypeError: items[i].toggle is not a function
    updateHiddenState jQuery
load.php:2:567
GEThttp://internalwiki.blabla.com/internalwiki/logos/internalwiki.ico
[HTTP/1.1 200 OK 0ms]

GEThttp://internalwiki.blabla.com/internalwiki/resources/src/mediawiki.skinning/images/magnify-clip-ltr.svg?8330e
[HTTP/1.1 200 OK 0ms]
Yaron Koren (talkcontribs)

Okay - it's not surprising that this error message does not show up in debug mode. It sounds like a timing problem (some JS is getting called before it is defined), and the timing is quite different in debug mode. What version of Header Tabs are you running?

Jongfeli (talkcontribs)

I updated the all extensions early December 2020, Header Tabs has version: 2.0 (adfd26a)

Wiki config:

Product Version
MediaWiki 1.35.0
PHP 7.3.23 (cgi-fcgi)
MariaDB 10.4.11-MariaDB
ICU 64.2
Elasticsearch 6.5.4
Yaron Koren (talkcontribs)

Alright. My guess is that the Header Tabs lack of display is a symptom of a problem with some other extension or skin... that error message, "items[i].toggle is not a function", doesn't seem to relate to anything in the Header Tabs code. Actually, I have no idea what that is coming from. If you create a wiki page with just tabs, or just tabs and text, do the tabs ever fail to load?

Jongfeli (talkcontribs)

Okay maybe this helps, I can reproduce the fault on our TestWiki by purging a page with ?action=purge.

Then I disabled all extensions one at a time until I found out that when disabling the Page Forms extension the page loads normally and I can not reproduce the fault anymore.

I have done this several times, disabling and enabling Page Forms and the fault can only be reproduced when Page Forms and Headertabs are both enabled.

I tried to do the same on the SMW Sandbox Page but I only managed to reproduce this a couple of times. See screenshots below.

I just tried it again by pressing purge page on https://sandbox.semantic-mediawiki.org/wiki/Utilisateur:Jongfeli and it failed again.

It seems that somehow after "X" time a purge page can results in this fault.

Jongfeli (talkcontribs)

Okay, today I updated both Headertabs and Page Forms to Master and suddenly it does not matter if Page Forms is enabled or not, the fault always appears.

To make a long story short, Page Forms has "nothing" to do with it (but I am not sure about this).

When you use Page Forms Master and Headertabs release 1_35 it works just fine.

The page now reports This page is using the deprecated ResourceLoader module "jquery.ui". Please use OOUI instead. but it works just fine.

I assume the move in Headertabs from jquery.ui to OOUI is somehow causing this problem after a page has been purged with &action=purge.

Maybe it has something to do with the fact that a &action=purge is now done with POST that needs to be confirmed.

I did find the items[i].toggle in the below js script.

For now the 1_35 version of Headertabs fixes the problem with an added bonus, we have our familiar blue tabs back :-)

    OO.ui.StackLayout.prototype.updateHiddenState = function (items, selectedItem) {
      var i,
      len;
      if (!this.continuous) {
        for (i = 0, len = items.length; i < len; i++) {
          if (!selectedItem || selectedItem !== items[i]) {
            items[i].toggle(false);
            items[i].$element.attr('aria-hidden', 'true');
          }
        }
        if (selectedItem) {
          selectedItem.toggle(true);
          selectedItem.$element.removeAttr('aria-hidden');
        }
      }
    };
Yaron Koren (talkcontribs)

Thank you for investigating this - including finding that part of the JavaScript code. All of what you're saying makes sense, but I can't reproduce the problem, with MW 1.35 and the latest Header Tabs code. Does this happen for you with every page that uses Header Tabs - even a very simple one?

Jongfeli (talkcontribs)

No it does not happen on every page, only on pages with multiple tabs (6 to 12) which contain SMW queries.

They take relatively long to load +/- 5 to 10 seconds. Like the example on the SMW sandbox.

See: https://sandbox.semantic-mediawiki.org/wiki/Utilisateur:Jongfeli

On the SMW sandbox site it only happens sometimes, not every time you purge a page. So there is definitely something going on.

I will test some more in the SMW sandbox, maybe we can get it to fail all the time.

Yaron Koren (talkcontribs)

I doubt that you can ever get some page to fail all the time, since this sounds like a timing-related issue. I wonder, though, if you can figure out what the simplest page is that will sometimes fail. Are SMW queries always required, for example?

Jongfeli (talkcontribs)

I do not know if SMW queries are required, I do not think so. like you said it has probably something to do with timing.

Today I tried to figure out what the difference is between pages that work and pages that don't.

I thought I found it when I noticed there where UseCDNCache: "false" codes in the cookie request when it worked and not when it failed.

Maybe it has something to do with it but I am not sure, it was introduced in MW-1.34 see: Manual:$wgUseCdn

The only thing that really helped was disabling the HTTP cache in the Firefox debug mode, then it always loads correctly (but takes forever).

This would suggest there is sometimes something wrong with caching or cookies.

Revansx (talkcontribs)

@Jongfeli - Where did you land on this? I am experiencing it too.

Jongfeli (talkcontribs)

Hello @Revansx. We reverted back to an older version of Header Tabs with the old style tabs not using OOUI.

But also this older version does not work correctly all the time and sometimes only loads the first tab but it does not break the page like the more recent versions and as shown in the screenshot above. This is on MW 1.35.6 I am not sure which version this is, it says 1.3 but that is probably not correct.

I did not investigate any further but the problem is probably still there when using master.

Are you using SMW as well?

Revansx (talkcontribs)

Hi @Jongfeli, thanks for responding. Sounds like we're in the same boat. Yes, I use SMW as well. The HeaderTabs mainatiners don't seem to be able to reproduce this problem and so it has been suggested that this issue may only manifest when HeaderTabs is used with some other extension (maybe SMW, but we can't actually say which until we can reliably re-produce the problem) .. That said it seems clear that the problem has not been solved.

When it does glitch, it doesn't seem to produce any errors or diagnostic info, so my my new strategy is to seek help from the HeaderTab developers for help in adding some debugging tools in the extension. I'll provide an update here if I am able to make any progress on this problem. Please do likewise. Cheers!

Jongfeli (talkcontribs)

Unfortunately the SMW sandbox site is still down. I was able to reproduce it there to.

Revansx (talkcontribs)
Revansx (talkcontribs)
Revansx (talkcontribs)

For MW 1.34.x + HeaderTabs 1.3 + SMW 3.2.3, we were finally able to solve the HeaderTabs issue where the header tabs don't always load. To do so we had modified: /opt/htdocs/mediawiki/extensions/HeaderTabs/HeaderTabs.hooks.php from:

     85                 $resourceLoader->register( [
     86                         "ext.headertabs" => [
     87                                 'localBasePath' => $htDir,
     88                                 'remoteExtPath' => 'HeaderTabs',
     89                                 "scripts" => "skins/ext.headertabs.core.js",
     90                                 "dependencies" => [
     91                                         $jquiTabsModule
     92                                 ]
     93                         ]
     94                 ] );

to

     85                 $resourceLoader->register( [
     86                         "ext.headertabs" => [
     87                                 'localBasePath' => $htDir,
     88                                 'remoteExtPath' => 'HeaderTabs',
     89                                 "scripts" => "skins/ext.headertabs.core.js",
     90                                 "dependencies" => [
     91                                         $jquiTabsModule,
     92                                         "ext.smw.tooltips",
     93                                         "ext.smw.style"
     94                                 ]
     95                         ]
     96                 ] );

specifically we added the SMW resources "ext.smw.tooltips" and "ext.smw.style" as dependencies for Headertabs and that seems to have solved the issue. (fingers crossed)

Fgneba (talkcontribs)

@Revansx does this solution still work for you? I tried and on some pages, HeaderTabs still breaks. In the pages where it breaks, I inspected the page source and realized that the CSS modules for headerTabs does not load on those pages. In particular, this link tag is missing:

<link rel="stylesheet" href="/mediawiki/load.php?lang=en&amp;amp;modules=ext.headertabs.styles%7Cjquery.tablesorter.styles%7Cmediawiki.widgets.styles%7Coojs-ui-core.icons%2Cstyles%7Coojs-ui.styles.indicators%7Cskins.vector.styles.legacy&amp;amp;only=styles&amp;amp;skin=vector">

Krabina (talkcontribs)

We are also running in this problem. Was there in MW 1.31 and is still there in MW 1.35. On arbitrary pages, eg. https://www.geschichtewiki.wien.gv.at/Hofball you should no be able to see the QR code on the right, it should bin in the HeaderTab. Reoloading loads the page just fine. It does not have anything to do with the QRLite extension.

Jongfeli (talkcontribs)

Okay I just want to write this down so I don't forget and in the hope that others will recognize this.

We still have the above problem after upgrading MW and all extensions (MW-1.39.5 / PHP 8.1.24) but we have noticed a couple of things:

  • It is only a real problem when working from home via a (slower) VPN connection compared to a wired office workplace.
  • It "only" happens when using Firefox. Chrome and Edge do not seem to be affected by it.
  • It happens mostly on "heavy" pages that take longer to load because of bigger result sets for SMW and Externaldata queries.
  • When requesting the page again with CTRL-F5, bypassing browser cache it loads just fine.

I can click around in Chrome and Edge but the problem never pops up. In Firefox it is very easy to break the header tabs. So it seems that Firefox is handling what to load when from cache differently then Chrome or Egde. The result, when I am correct, is that the JavaScript libraries are not loaded yet when the tabs are being generated.

Reply to "Header Tabs sometime fails to load"