There’s no TOC in articles either – this preference applies only on small screens, where the TOC is hidden in all namespaces. If the user decided to uncollapse all sections anyway, it’s their decision. (A reason to do this could be searching: browsers’ built-in searchers ignore content in collapsed sections, which is just as much of a problem on talk pages as in articles.)

In T322628#8386556, @Tacsipacsi wrote:

If the user decided to uncollapse all sections anyway, it’s their decision. (A reason to do this could be searching: browsers’ built-in searchers ignore content in collapsed sections, which is just as much of a problem on talk pages as in articles.)

Good point, @Tacsipacsi.

Tho, doing what this ticket describes would maintain – what I understand to be – the current behavior of the Expand all sections preference: when enabled, people who visit a talk page will find all of the sections collapsed within the overlay MobileFrontend implements. [i]

The above leads me to wonder whether people would find an option to expand/collapse all sections on a per-page basis (T269954) more intuitive than having to know about a setting within preferences.

Setting enabled	Talk page sections collapsed

In T322628#8386556, @Tacsipacsi wrote:

There’s no TOC in articles either – this preference applies only on small screens, where the TOC is hidden in all namespaces. If the user decided to uncollapse all sections anyway, it’s their decision. (A reason to do this could be searching: browsers’ built-in searchers ignore content in collapsed sections, which is just as much of a problem on talk pages as in articles.)

Since T216789, you can now search collapsed sections with browsers that support the hidden=until-found attribute: https://caniuse.com/mdn-html_global_attributes_hidden_until-found_value

Nice, but as long as not all Grade A browsers support it (currently only 3 out of 8 do, not even Chromium-based Opera does), it should not be relied upon.

In T322628#8430380, @Tacsipacsi wrote:

Nice, but as long as not all Grade A browsers support it (currently only 3 out of 8 do, not even Chromium-based Opera does), it should not be relied upon.

Indeed, but it is a problem that should eventually be solved by browser vendors, so that lowers our prioritisation of working on a fix.

Change 865702 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/MobileFrontend@master] Always collapse sections when 'collapsible-headings-collapsed' body class present

https://gerrit.wikimedia.org/r/865702

Change 865703 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Add 'collapsible-headings-collapsed' body class

https://gerrit.wikimedia.org/r/865703

In T322628#8432705, @Esanders wrote:

Indeed, but it is a problem that should eventually be solved by browser vendors, so that lowers our prioritisation of working on a fix.

But the question here is not whether you actively fix something that’s broken, rather whether you break something (in Firefox, Safari and co.) that has worked before.

In T322628#8452114, @Tacsipacsi wrote:

In T322628#8432705, @Esanders wrote:

Indeed, but it is a problem that should eventually be solved by browser vendors, so that lowers our prioritisation of working on a fix.

But the question here is not whether you actively fix something that’s broken, rather whether you break something (in Firefox, Safari and co.) that has worked before.

Expand-all-sections has never worked on talk pages, due to talk pages using the special MobileFrontend view.

Change 865702 merged by jenkins-bot:

[mediawiki/extensions/MobileFrontend@master] Always collapse sections when 'collapsible-headings-collapsed' body class present

https://gerrit.wikimedia.org/r/865702

Change 865703 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Add 'collapsible-headings-collapsed' body class

https://gerrit.wikimedia.org/r/865703

In T322628#8454376, @Esanders wrote:

Expand-all-sections has never worked on talk pages, due to talk pages using the special MobileFrontend view.

Right. So you indeed did not actively break something, you just actively worked on avoiding to have it fixed. A bit better, but you still put work in ensuring that something is broken.

In T322628#8456582, @Tacsipacsi wrote:

Right. So you indeed did not actively break something, you just actively worked on avoiding to have it fixed. A bit better, but you still put work in ensuring that something is broken.

Isn't that the story of this whole project? ;) We really worked hard to avoid fixing talk pages for real!

Personally I agree that collapsing all topics is not the ideal solution, but it doesn't seem that important to me, and being deliberate about UI changes has worked out for us in the past, so I understand why we've decided on that, even if I sometimes wish we'd be bolder about making changes (we probably could have enabled the discussion tools on mobile a year ago and it still would have been a massive improvement over the current UI).

In T322628#8457508, @matmarex wrote:

In T322628#8456582, @Tacsipacsi wrote:

Right. So you indeed did not actively break something, you just actively worked on avoiding to have it fixed. A bit better, but you still put work in ensuring that something is broken.

Isn't that the story of this whole project? ;) We really worked hard to avoid fixing talk pages for real!

Of course. ;) But taking it seriously, the goal of the project is to improve the experience for junior (and partly senior) contributors while allowing senior contributors/power users to continue to handle talk pages just like any other wikitext page if/when they don’t need the new features. This change breaks this: users can’t continue to have talk page sections open by default (not even in “read as wiki page” view).

In T322628#8461173, @Tacsipacsi wrote:

... This change breaks this: users can’t continue to have talk page sections open by default (not even in “read as wiki page” view).

Conversely, if you are user who wants article pages to be expanded, but talk pages to be collapsed, then changing it to behave how you are describing would "break" the experience for those users.

If we were to support expanding sections on talk pages it should probably be a separate preference so users can configure it separately from articles. @ppelberg will file a new task for this, although I can't promise it will be a priority.

Okay, you’re right, honoring the user preference can also be seen as “breaking”. Then I think the precise former status quo should be restored (unless/until a separate user preference is created): DT-enhanced talk pages should always collapse sections, regardless of the user preference (like the MobileFrontend overlay), but the “read as wiki page” view should honor the preference (as it has always done).

In T322628#8464283, @Esanders wrote:

If we were to support expanding sections on talk pages it should probably be a separate preference so users can configure it separately from articles. @ppelberg will file a new task for this, although I can't promise it will be a priority.

✅ Done. See: T325573.

In T322628#8468526, @Tacsipacsi wrote:

Okay, you’re right, honoring the user preference can also be seen as “breaking”. Then I think the precise former status quo should be restored (unless/until a separate user preference is created): DT-enhanced talk pages should always collapse sections, regardless of the user preference (like the MobileFrontend overlay), but the “read as wiki page” view should honor the preference (as it has always done).

@Tacsipacsi: for the time being, we'd like to hold off on investing additional effort into the mobile talk page Read as wiki page view considering we are planning to eventually deprecate it by way of T280417.

With the above said, if we come to learn that people need "expand all" functionality, we can revisit the decision above.

FYI: I'm going to close this ticket in the next day or so, so let's move any follow up conversation to T325573.

The problem is that T325573 will be fixed some time, T280417 will be done “eventually”, while the “Read as wiki page” view has been broken now. Until that “eventually”, there’s plenty of time to restore the former status quo (unless that “eventually” becomes a definite, not-too-far date).