Issued a PR to address this issue in part: https://github.com/LayeredStudio/whoiser/pull/92

| Q | A | ------------- | --- | Bug fix? | yes | New feature? | no | Deprecations? | no | Tickets | Fix #91 | License | MIT

Current parsing approach combines various Created values (e.g. Created, Registrant Created, and Admin Contact Created) to create a single, invalid date string.

Improves .it parsing to preserve date structure and more.

Thank you for the detailed response. Permit me a possibly silly question, but is it safe to assume a TLD will only ever have a single structure style? For instance, I'm noticing the library doesn't presently parse .it results accurately (e.g. it blends the created property for the Registrant in with the created property for the domain. The registrant properties are preceded by white-space, and follow the Registrant line). I suspect creating a parser for this style would be fairly simple, but I wondered if the parser would apply to all .it domains, or if some endpoints may return a different document structure.

Description

I'm noticing quite a few different date formats in the returned data. For example, YYYY.MM.DD, YYYYMMDD, YYYY-MM-DD, YYYY-MM-DDTHH:MM:SSZ, and more. Would it be worth considering a date-normalization step, aiming to deliver a single format? Or, is there a reason why somebody might wish to preserve the original structure?

If there's an interest here, I might be able to contribute a PR. I would appreciate any pointers to previous commits which might offer guidance for how best to integrate a feature like this. Thanks!

Version(s) affected: 1.14.0

Description

Error: TLD <domain with one of the aforementioned TLDs> not found
    at whoisTld (whoiser.js:118:9)
    at async whoisDomain (whoiser.js:137:15)

@p1-0tr So far, so good. I installed that build, and the Docker engine is now up and running. I'll return if anything changes.

@p1-0tr That doesn't appear to resolve the issue for me. Please see DC821352-A5DF-4E10-A5B1-FC88B1A7336D/20230123162956 for diagnostics.

Bug Report

When retrieving a channel's schedule, the segments property on the response may in fact be null. This is contrary to what Twitch has described in their documentation. For example, api.twitch.tv/helix/schedule?broadcaster_id=154510813 is (at the time of this writing) serving the following response:

{
    "data": {
        "segments": null,
        "broadcaster_id": "154510813",
        "broadcaster_name": "EvrimAgaci",
        "broadcaster_login": "evrimagaci",
        "vacation": null
    },
    "pagination": {}
}

Attempting to call schedule.data.segments will throw the following:

…\HelixSchedule.js:21
        return this[common_1.rawDataSymbol].segments.map(data => new HelixScheduleSegment_1.HelixScheduleSegment(data, this._client));
                                                     ^

TypeError: Cannot read properties of null (reading 'map')
    at get segments [as segments] (…\HelixSchedule.js:21:54)

This is due to the assumption that segments is present, and is iterable:

https://github.com/twurple/twurple/blob/331ce22840ed88894e00d638c0a236130be41e91/packages/api/src/api/helix/schedule/HelixSchedule.ts#L24-L26

Expected behavior

According to both Twitch's documentation (which is beyond the control of this project) and that of Twurple (which is not), schedule.data.segments should return a list of HelixScheduleSegment objects.

This happened to me just now in v1.21.65 (presently Brave Beta):

From https://twitter.com/kentcdodds/status/1364736650555756544, I scrolled down to the following and clicked Tip:

The tipping banner did not show any issue with displaying the publisher's username:

Originally posted by @jonathansampson in https://github.com/brave/brave-browser/issues/8265#issuecomment-785569253

No repro for me either. Closing.

Issue

The authors template has an element obstructing the view.

Screenshot

Checklist

• [x] Example URL included
• [x] Screenshot included

Fixes #20

• Introduces .gitignore to exclude .DS_Store
• Removes local copies of jQuery, jqFlip, and Bootstrap (replaced with same-version CDN resources)
• Modifies index.html to use Bootstrap classes for centering elements.
• Removes non-ASCII characters from 'WOMBAT' image filename.
• Migrates captions.py to ~root/utils/
• Removes some unused files, and fixes a minor CSS syntax typo.
• Modifies captions.py to write results to captions.json
• Modifies index.html to load captions.json file (via index.js).
• Simplifies project structure with ~root/assets/ directory.

Tested locally to confirm no breaking changes.

Various Improvements

Introduces .gitignore to exclude .DS_Store Removes local copies of jQuery, jqFlip, and Bootstrap. Modifies index.html to use Bootstrap classes for centering elements. Removes non-ASCII characters from 'WOMBAT' image. Migrates captions.py to ~root/utils/ Removes some unused files, and fixes a minor CSS syntax typo. Modifies captions.py to export results to captions.json Modifies index.html to load captions.json file. Simplifies project structure with assets directory.

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.74.2
• OS Version: 10 (19045.2364)

Steps to Reproduce:

1. Create environment variable named "DEBUG"
2. Launch node in integrated terminal, run process.env.DEBUG
3. Launch node in external instance of cmd.exe, run process.env.DEBUG

undefined is returned for integrated terminal, but not for external cmd.exe instance.

👉 Considerably more information here: https://stackoverflow.com/q/74966735/54680

The issue doesn't reproduce for all environment variables. I evaluated 86 different variables with Visual Studio Code (integrated terminal), PowerShell, and Command Prompt. There was something about "DEBUG" (and oddly enough, "DEEBUG"), however.

Visual Studio Code, and nearly all of its child processes, have the DEBUG variable in their environment. The only exception is the --type=ptyHost child process; it does not have the variable in its environment.

Nice work, @josStorer!

It may be enough to simply block a particular onboarding request to prevent this issue entirely: https://twitter.com/konarkmodi/status/1595176344266035201

Description

When an unauthenticated user visits Twitter.com, and begins scrolling through recent posts on a channel, they will soon encounter a modal inviting them to sign-up/in to continue. This modal obscures the content on the page.

Brave should consider/explore a method for clearing the modal, and enabling users to continue viewing the obscured content. If a user wishes to sign-up/in, they can do so from the sidebar.

Steps to Reproduce

1. In a private window, navigate to https://twitter.com/brave/
2. Scroll down the page until a modal is presented

Expected result:

User should not be interrupted by the non-dismissible modal.

Reproduces how often:

Easily.

Desktop Brave version:

1.45.127

Other Additional Information:

Discussed on Twitter: https://twitter.com/BrendanEich/status/1594925703807606786

Miscellaneous Information:

Extensions exist currently which aim to achieve similar results: https://chrome.google.com/webstore/detail/breakthrough-twitter-logi/ohhifopcgokjpbnppnmjbdnjnfcfnlep

+1 to support for checksums when syncing.