theoldreader.com - "Post" titles are not visible

[webcompat-bot]

URL: https://theoldreader.com/

Browser / Version: Firefox Mobile 98.0
Operating System: Android 11
Tested Another Browser: Yes Chrome

Problem type: Design is broken
Description: Items not fully visible
Steps to Reproduce:
Website is not showing my feed. However in Chrome it shows my feed.

View the screenshot

Browser Configuration

• gfx.webrender.all: false
• gfx.webrender.blob-images: true
• gfx.webrender.enabled: false
• image.mem.shared: true
• buildID: 20220117035808
• channel: nightly
• hasTouchScreen: true
• mixed active content blocked: false
• mixed passive content blocked: false
• tracking content blocked: false

View console log messages

From webcompat.com with ❤️

[softvision-oana-arbuzov]

Thanks for the report, but I'm not able to reproduce the issue. For me the "Feed" ("Posts" and "News") section is displayed similar to Chrome.

A Compatibility issue here is that the "Post" title is not visible on Firefox.

Affected area:

<a href="/feeds/aed846f0d597789927a7ce68/view" class="label label-feed" data-pjax="" data-replace-href="feedHrefByFeedId('aed846f0d597789927a7ce68', '', 'https://www.apartmenttherapy.com/apartment-lofted-bed-diy-redo-1500-dollars-37027493?utm_source=RSS&amp;utm_medium=feed&amp;utm_campaign=Category%2FChannel%3A+main')" data-replace="feedTitleByFeedId('aed846f0d597789927a7ce68','www.apartmenttherapy.com')">...</a>undefined</div>

Note: The above issue is not reproducible on Chrome.

Tested with:
Browser / Version: Firefox Nightly 98.0a1 (🦎 98.0a1-20220119093435)
Operating System: Google Pixel 5 (Android 12) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density), Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)

Moving to Needsdiagnosis for further investigation.

[qa_03/2022]

[karlcow]

This is a regression which is created by the recent release of groupBy in Firefox Nightly.

The site has its own implementation

    /***
     * @method groupBy(<map>, [fn])
     * @returns Object
     * @short Groups the array by <map>.
     * @extra Will return an object with keys equal to the grouped values. <map> may be a mapping function, or a string acting as a shortcut. Optionally calls [fn] for each group.
     * @example
     *
     *   ['fee','fi','fum'].groupBy('length') -> { 2: ['fi'], 3: ['fee','fum'] }
     +   [{age:35,name:'ken'},{age:15,name:'bob'}].groupBy(function(n) {
     *     return n.age;
     *   });                                  -> { 35: [{age:35,name:'ken'}], 15: [{age:15,name:'bob'}] }
     *
     ***/
    'groupBy': function(map, fn) {
      var arr = this, result = object.extended(), key;
      arrayEach(arr, function(el, index) {
        key = transformArgument(el, map, arr, [el, index, arr]);
        if(!result[key]) result[key] = [];
        result[key].push(el);
      });
      return result.each(fn);
    },

I hope this is not widespread, because that will create issues.

@codehag this is probably of interest for you.

So let's put this into needscontact.
Also @wisniewskit do you know if a sitepatch can be written for this one.

[webcompat-bot]

Generate outreach template

[karlcow]

Duplicates in #98519

[karlcow]

Probably @jfiorato and @krasnoukhov can help here.
A solution would be to test first if the browser support groupby and/or to change the name of their function.

[wisniewskit]

do you know if a sitepatch can be written for this one

Yes, I believe so. I'll take a closer look after some sleep.

[codehag]

Yes, this is the same library for the other regression. I will speak with the champion. Please ping me if there are others. We are currently the first browser testing this new API.

The problem is that the library is detecting if there is a browser implementation for groupBy, and not replacing that browser version with its own. The api that the library uses is different then the specified one, you can see the detailed issue here

As groupBy is used by the library at start up, even if the site author is not using groupBy, it will throw. This has been patched in the library, but the site authors need to upgrade: tc39/proposal-array-grouping#37 (comment)

We may be looking at a rename of the proposal unfortunately.

[karlcow]

@codehag If we could detect the library, Maybe a site intervention would be possible given that there is https://bugzilla.mozilla.org/show_bug.cgi?id=1750812#c12

[karlcow]

Though other browsers would be impacted as well. That reminds me of MooTools 1.2 and contains which led to use includes.

[codehag]

@codehag If we could detect the library, Maybe a site intervention would be possible given that there is https://bugzilla.mozilla.org/show_bug.cgi?id=1750812#c12

Work towards detecting the library is underway: https://docs.google.com/spreadsheets/d/1p6sbgB7gsZ7jzKlaKKG5nx9oVYqqJGrwKCzgVO4UpdU/edit#gid=1197417696

We know of 254 sites that use affected versions, this grows to 660 if we include sites that we can't categorize based on HTTP-Archive data.

[rockwellwindsor]

Hey everyone. Just directed to this post by a user who submitted a ticket for The Old Reader, actually submitted the original ticket that alerted us to this issue, and followed up with this link.

It appears to be related to sugarJS, is that correct?

[ljharb]

@rockwellwindsor the implication is that if the website updates to a newer version of sugarjs, that the problem won't affect them, yes.

[karlcow]

@rockwellwindsor yes if sites using SugarJS adjust, it will make possible for the standard organization defining JavaScript to be able to use the keyword groupBy in the future version of the language. If the clash is too important, then the standard groupBy will have to find another name because of the name clash.

Updating to a newer version of SugarJS is fixing the issue. :)

Thanks for chiming in.

[rockwellwindsor]

@karlcow When we were first contacted about this issue I tracked it down to sugarJS. Unfortunately this was being brought in as a dependency and that initiated a cascading string of updates and upgrades that I am still working on.

[karlcow]

Thank you!