Regression bug of requests with wrong url sent from widgets.js

[falsandtru]

In these days, the twitter widget often doesn’t work because of requesting a wrong url like this:

https://example.com/null/?callback=__twttr.callbacks.cb0&ids=1047627723500179457%2C1048057228219961344%2C1048058437408448513-t%2C1048238864572268546%2C1048526885775323140%2C1048538794566115328%2C1048591286150860800%2C1048622251166203905%2C1048761085166116864%2C1048771100585250816%2C1048817638397235200%2C1048819961446072320%2C1048823604748541953%2C1048823810160349185%2C1048841517354311682%2C1048845698420985857%2C1048862068588212225%2C1048870191063416832%2C1048904208844386304%2C1048905392271413249%2C1048914058777247746%2C1048915836973412352%2C1048935575787433984%2C1048940727823032321%2C1048947367343415296%2C1048955590196641792%2C1048958351306940417%2C1048958943136030720%2C1049051205836492800%2C1049071464014475264%2C1049085704121200640%2C1049126304853852160%2C1049133733956046848%2C1049140518016307203%2C1049142576576487424%2C1049150455350095873%2C1049152805414494209%2C1049185273945325568%2C1049206719635578880%2C1049210566084939777%2C1049214604130246657%2C1049223512710213632%2C1049231307211911168%2C1049240755712081920%2C1049244585317154817%2C1049246209452388353%2C1049268486357188609%2C1049297150050357248%2C1049302129972633600%2C1049320262825467905%2C1049326688046276608%2C1049328253004079107%2C1049368977921564672%2C1049519002802737154&lang=ja&suppress_response_codes=true&theme=light&tz=GMT%2B0900

Looks like this is a regression bug of My User timeline Twitter widget is causing a "null" page request.

The bug appears when a request is instantly made after the widget is loaded. So if we put a delay about 1 second after there, requests sent from widget works fine. However, this workaround is invalid for tweets embedded before loading the widget because the widget wrongly processes them instantly.

[evansobkowicz]

Hi @falsandtru,

Can you please provide more info about this issue? The url to the page where this is happening, the embed code you’re using, and the os & browser/version you’re using would be really helpful to debug this further.

Thanks!

[falsandtru]

Please try the following steps:

1. Clone https://github.com/falsandtru/securemark and checkout v0.85.2.
2. Run npm i && bundle install && npm -g i gulp.
3. Run gulp view.
4. Open the displayed url like http://127.0.0.1:4000/securemark/ with secret or guest window of Chrome.
5. You’ll see a failure of tweet rendering and a wrong request.
6. If not, reload the window. It will appear several times in 10.

This problem appears on all websites with the low probability but looks like it appears with the high probability when a browser has many extensions.

[falsandtru]

@evansobkowicz Can you see the repro?

[evansobkowicz]

Hi @falsandtru,

Can you please provide a live URL that I can look at without pulling your code?

Thanks!

[falsandtru]

I couldn’t provide an example but I found the cause of the problem!

null comes from the following code by the timeout processing because the timeout value is only 400ms! It is too short!! Please give the long value enough (Probably it should be over 3 seconds).

https://platform.twitter.com/js/tweet.f370c308d0fc15068ffa28ad5e204dd3.js:formatted

        function o(e) {
            w.timeout(u(p.tweetBatch()), T).catch(function() {
                return g.devError("Settings promise failed to resolve in batch_fetch_html"),
                null
            }).then(function(t) {
                c(t, e)
            })
        }
        function c(e, t) {
            var n = m(t, r);
            C.forIn(n, function(t, n) {
                var r = t.split(k)
                  , o = r[0]
                  , c = r[1]
                  , d = i(o, c, n)
                  , u = f(a, null, n)
                  , l = f(s, null, n);
                b.fetch(e, d, h).then(u, l)
            })
        }
        function d() {
            this.requestQueue = new l(o)
        }
        var u = n(227)
          , l = n(40)
          , h = n(228)
          , f = n(15)
          , p = n(78)
          , m = n(44)
          , b = n(136)
          , v = n(138)
          , g = n(10)
          , w = n(34)
          , C = n(12)
          , E = "en"
          , x = "light"
          , k = ","
          , T = 400;

[haaretzcom]

Hi,

We experience exactly the same issue on our mobile web site And App, when opening an article with android device.

it’s requesting a wrong URL like the following:

https://www.haaretz.co.il/null?callback=__twttr.callbacks.cb0&ids=1050068255828774912&lang=en&suppress_response_codes=true&theme=light&tz=GMT%2B0300

is there a solution for that?

[falsandtru]

@evansobkowicz

[falsandtru]

Note that even when we set a long value to the timeout, that request sometimes has failed by some ad-blockers like Ghostery. But if we stop it, twitter widget works fine. Thus changing the timeout value is the perfect solution.

[pcanterini]

Hi @evansobkowicz ,

We seem to be having a similar issue when loading tweets in our section pages on Safari for mac, iOS as well as android devices. Bug reports for this issue spiked sometime later last week without any recent code changes on our end.

We have noticed tweets fail to load via twttr.widgets.load(elem) when the iframe widget takes a bit longer to process (I haven’t debugged further).

Here is an example:

Screen Shot 2018-10-14 at 19.29.57.png

Public page:

Houston Texans

Steps to repro:
Load the page a few times on safari for mac while toggling caching on and off (in dev network tab) a few times.
When tweets fail to render correctly notice the call to /null and the slower processing time for the widget iframe

We are not entirely sure the issue is not on our end at this point but since this looked like a similar bug that was already filed we decided to join the conversation.

We appreciate any feedback.

Thanks!

[evansobkowicz]

Thanks for all the reports! We’re looking into this.

[evansobkowicz]

@falsandtru @pcanterini @haaretzcom

Thank you all for the reports on this. We’ve found the cause of the null url and resolved the issue. Please let us know if you’re still seeing this issue (after clearing your widgets.js cache).

Thanks!

[falsandtru]

Strange but solved.

        function o(e) {
            w.timeout(u(p.tweetBatch()), T).catch(function() {
                return g.devError("Settings promise failed to resolve in batch_fetch_html"),
                p.tweetBatch()
            }).then(function(t) {
                c(t, e)
            })
        }

[pcanterini]

Verified on my end as well, it doesn’t seem to be happening anymore (https://d.pr/i/pnpyLk).
Thanks for looking into this so promptly.

Cheers!

[system]

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.