原寸画像(:orig)の劣化を抑えるには？（アップロードの前に）

24bpp（アルファチャンネル無し）透明ピクセル無しのPNG画像はJPEGに変換されてしまうため、PNG形式のままで表示（ダウンロード）させたい場合は、32bpp（アルファチャンネル有り）に変換透明ピクセルを追加した後にアップロードするのが今のところ解決方法となる。
ただし、32bpp のPNG 画像が :orig を付けて原寸でダウンロードできた場合も、元画像そのものがダウンロードできるわけではなく、Twitter側で変換されたものになる（アップロードしたものとはファイルサイズ等が異なっている）。

既存の画像については、例えばPNG 32bpp変換 | しぇ庫を使って簡単に24bppから32bppへ変換できる（2016/02/27現在、Twitterの仕様変更により、透明ピクセル追加の対応検討中とのこと→2016/02/28に改訂版がリリースされた）。

TwitterでPNGがJPEG変換されないよう32bppに変換するツール #PNG32bpp変換を公開しました。D&D、コピペ、「送る」から呼び出せて、投稿欄へ直接ドロップできますhttps://t.co/4rvmWQnyaepic.twitter.com/20OBfopz75

— シェゴ (@syego) 2016年2月21日

Twitter社の仕様変更により本ツールで生成した画像もJPEG変換されるようになってしまいました。画像生成時に適当に透明ピクセルを設定するよう変更を検討中です。https://t.co/4rvmWQnyae

— シェゴ (@syego) February 27, 2016

Twitterの仕様変更により、透明画素が無い場合や3MBを超える場合もJPEG変換の対象になったようなので、苦し紛れに対応したバージョンをリリースします。https://t.co/4rvmWQnyae#PNG32bpp変換pic.twitter.com/ZZFmwp8FIc

— シェゴ @ PNG変換ver0.2公開 (@syego) 2016年2月28日

原寸画像を表示・保存するためのブラウザ拡張機能／スクリプト

PC 用ブラウザで、Web 版 Twitter の原寸画像を表示したり、ダウンロードしたり出来る拡張機能／ユーザースクリプト等。
furyu.hatenablog.com
いちいち :orig をつけたり、ダウンロード時に拡張子を修正するのが面倒だったので、↓の二つを参考に、独自機能も付け加えて自作したもの。原寸表示・ダウンロード共に対応。Google Chrome、Opera、Firefox（Greasemonkey）に対応（ブックマークレットは一部機能を IE11 にも対応）
hogashi.hatenablog.com
chrome.google.com

試行錯誤など

豆知識：
PCのブラウザから、Web版Twitterに縦もしくは横が1pxの画像を添付してツイートしようとすると、「サーバー内部のエラー」とかなってツイートできない。

— 風柳 (@furyutei) April 13, 2016

8001px × 8001pxの透過png→8000px × 8000px の jpg:orig
8000px x 8000pxの透過png→8000px × 8000px の jpg:orig
原寸画像も 8000 ピクセルまで？
どちらも 270KB強だが jpg になったし

— 風柳 (@furyutei) April 13, 2016

スマートフォンで公式アプリを使った場合、最大横2048pxあたりまで（アプリ側で）縮められてしまうのかも…？

イオンモールが見えたので、もう迷う心配は無かろうと、ちょっと近くの公園（？）に寄り道…。 pic.twitter.com/SytQxs6ZlE

— 風柳 (@furyutei) April 1, 2016

ノートン 360 のライブアップデートで、インストール失敗

pip freeze や pip install が固まってしまう状態になった際、過去の経験

ノートン 360 のライブアップデートしたら、接続できるようになった…(苦笑)。
「特定の Web サイトにアクセスできない問題を解決する」https://t.co/gj7tTIsbFQ
力技だなぁ…。
※なお、その前にスマートファイアウォールを一時的に無効化して試してもダメだったhttps://t.co/ltL9TPmF8y

— 風柳 (@furyutei) 2018年2月21日

その後の復旧

上記の状態で、どうしようもないのでそのまま強制的に再起動すると*1、今度は、

のようなダイアログが現れた。
最初からこっちを出してくれ、と思わないでもない。
『サポートWebページに移動する』リンク先の指示に従って、『ノートン削除/再インストールツール』(NRnR.exe) をダウンロードして実行。
削除と再インストールを行うことで、なんとか復旧することができた。

viewportの主要なパラメータ

<meta name="viewport">の content の値

値	設定可能な値	説明
width	正の整数または文字列 device-width	ウェブサイトを描画したいビューポートの幅をピクセル数で定義します。
height	正の整数またはテキスト device-height	ビューポートの高さを定義します。どのブラウザーでも使用されていません。
initial-scale	0.0から 10.0までの、正の数値	デバイスの幅 (ポートレートモードでの device-widthまたはランドスケープモードでの device-height) とビューポートの寸法との比率を定義します。
maximum-scale	0.0から 10.0までの、正の数値	ズームの最大値を定義します。この値は minimum-scaleと同じまたはより大きくしなければなりません。そうではないときの動作は未定義です。ブラウザーの設定でこの規則を無視できます。また、iOS 10 以降は既定で無視します。
minimum-scale	0.0から 10.0までの、正の数値	ズームの最小値を定義します。この値は maximum-scaleと同じまたはより小さくしなければなりません。そうではないときの動作は未定義です。ブラウザーの設定でこの規則を無視できます。また、iOS 10 以降は既定で無視します。
user-scalable	yesまたは no	noを設定すると、ユーザーはページのズームができなくなります。既定値は yesです。ブラウザーの設定でこの規則を無視できます。また、iOS 10 以降は既定で無視します。

<meta>: 文書レベルメタデータ要素 - HTML | MDN

viewportを指定しないとどうなる？

viewport指定を省略した場合、モバイルデバイスでは、ブラウザが暗黙的にデフォルトのwidth値（ブラウザ毎に異なる、例えば980といった値）を用いて、これをウィンドウ（≒スクリーン）内に収めるように表示される。
例えば、デスクトップ向けのページなどで、横幅がこれより大きい値を前提として設計されていたら見切れてしまう。

device-width とは？

device-widthとは、モバイルデバイスが持つ画面（スクリーン）の論理解像度（ポイント・実質解像度・CSSピクセル）の横幅のことで、これはカタログに載っている解像度（画素数）とは異なる。
device-heightは同じく縦幅のことだが、ほとんど使うことはないと思われる。
例えば、iPhone X のディスプレイは5.8インチ・1125x2436ピクセルの解像度を持つが、device-widthは375（device-heightは812）となる。
すなわち、ブラウザのウィンドウで375px×812pxの画像を等倍で表示した場合、画面にピッタリと収まるサイズで表示されるということになる。

initial-scale とは？

基本的には、ページを表示した際の、最初の表示倍率（拡大率）のこと。
例えば、initial-scale=1 の時は等倍で、initial-scale=0.5の時は幅が半分に縮小（矩形としては4分の1）、initial-scale=2の時には幅が倍に拡大（矩形としては4倍）となる。

これだけならばよいのだが、ややこしいのが『条件によっては viewport の大きさに影響してしまう』ということ（後述）。

CSS

メディアクエリのブレイクポイント（@media (min-width: XXX) {...}）判定の基準となる。

JavaScript

viewportの指定によりブラウザのウィンドウの大きさが決まることになるため、window.innerWidth・innerHeightといったパラメータに影響する。
なお、window.screen.widthやwindow.screen.availWidthは、viewportの指定によらず一定で、デバイス固有の値（≒device-width）を持つ。

"width=device-width, initial-scale=1"で、万全!?

viewportについて調べていると、典型的な設定例として出てくるのは、

<metaname="viewport"content="width=device-width, initial-scale=1" />

のようなもの。

• viewport（≒ブラウザのウィンドウ）幅を device-width に
• 最初の表示倍率を 1 に

という指定。

適切なレスポンシブ対応（メディアクエリのブレイクポイントの設定）が行われている場合には、この設定で問題は無い。

レスポンシブ対応がなされていない場合

レスポンシブ対応がなされておらず、『とりあえず、デスクトップ用の画面を、モバイルデバイスでも横幅が綺麗に収まる形で表示したい』という場合の設定。
例は、横幅1000pxで設計されているページの例

<metaname="viewport"content="width=1000, user-scalable=no" />

本来ならば、width さえ指定しておけば、ブラウザが拡大率を適切に設定して、スクリーン内に収まるように調整してくれそうなもの。
ではなぜ user-scalable=no を設定しているのかというと、状況によってはこの自動調整がうまくいかないケース（等倍で表示されるケース）があったため。
うまく自動調整されない場合の原因は不明。
いずれにしても、user-scalable=no にするとユーザーが拡大縮小できなくなってしまい不便なので、早期にきちんとレスポンシブ対応すべきではある。

レスポンシブ対応が不完全な場合

スマートフォンには対応したのだけれど、ある範囲（例えば横幅768px～1199px）のデバイス（タブレット）だけ表示が見切れる（デスクトップ用に1200px前提でページ設計）という場合の設定。

<metaname="viewport"content="width=device-width, initial-scale=1" /><script>
(function(){'use strict';var min_screen_width_for_tablet = 768, // @media (min-width: <min_screen_width_for_tablet>px) { ... }    viewport_width_for_tablet = 1200,    screen_width = window.screen.width;if( min_screen_width_for_tablet <= screen_width ){document.querySelector('meta[name="viewport"]').setAttribute('content', 'width=' + viewport_width_for_tablet + ', user-scalable=no');}})();</script>

デフォルトとして、meta[name="viewport"]には"width=device-width, initial-scale=1"を指定しておき、JavaScript で window.screen.width によりデバイスのスクリーン幅（≒device-width）を調べ、条件に当てはまる場合だけ書き換えを行う。

initial-scale について

上記のとおり、initial-scaleは初期の表示倍率を示すほかに、条件によっては viewport の大きさに影響してしまう。
具体的には、

X = device-width / initial-scale
とするとき、
width < X となる場合には、viewport の幅として X が適用される（widthの指定は無視される）。

模様。
例えばdevice-widthが360のモバイルデバイスの場合に、
"width=640, initial-scale=0.5"
のような指定をすると、実際の viewport の幅としては 720（=360/0.5）が適用されてしまう

また、initial-scale に 1 未満の値を指定しても、状況によってはうまく縮小表示されないケースもある。
具体的な条件は不明。ただし、この場合でも、user-scalable=no と併用すれば正しく縮小表示される模様。

ブラウザによってウィンドウサイズ(innerWidth/Height)の決定方法が異なっている？

Google Chromeの場合

この最大領域の横幅は、document.body の大きさと viewport の minimum-scale により、以下のように決まっている模様。

• document.body の横幅が viewport の以下の場合には、viewport の幅
• document.body の横幅が viewport より大きい場合、device-width / minimum-scale と document.body の横幅のうち、小さい方

あくまで最大領域に応じて決まるため、実際のユーザーの拡大縮小操作には影響されない。

Firefoxの場合

【未確認】Safariの場合

【未確認】Windows Tablet / Phone について

Windows 系のモバイルデバイスについては、meta[name="viewport"] による指定は効かないため、別途、CSS で @-ms-viewport による指定が必要？
実機が無いこともあり、確認が取れていない。

追記

はけた氏（@excelspeedup）にもツイートでご指摘いただいたが、こういう場合は
interconnectit.com
を使うのが定石の模様。

Search Replace DB を使うと、

このように、Post meta value 等のシリアル化されたデータについても、それに考慮した変換を行ってくれる。

なお、実際に不具合で発生したサイトでも最初はこれを試そうとしたのだが、WordPress のバージョンの問題でうまく実行できなかったのであった……環境はなるべく最新のものを使おうね、というお話（自分が制作・管理していない場合、いかんともしがたいが・苦笑）。

参考

junjun-web.net

WordPress移行時にURLをSQLで直接一括置換はダメ！ 「Search and Replace for WordPress Databases Script」を使おう | infoScoop開発者ブログ

追記（2018/07/19）

SWSが本脅威を対策するためには、Refererなどを確認してリクエストの正当性を検証したり、CookieにSameSite属性を付与する手法などが考えられます。

ソーシャルウェブサービスにおける新たなプライバシー脅威「Silhouette」を発見：NTT持株会社ニュースリリース：NTT HOME

実は、このプライバシー脅威（Silhouette）への対策の影響だった、とか？

注意事項

content_scripts 内では、window.XMLHttpRequest や window.fetch は read-only になっているため、content.* で上書きしようとしてもできない。

自作スクリプト内ならば、使用するスコープの最初で、

const XMLHttpRequest = ( typeof content != 'undefined'&& typeof content.XMLHttpRequest == 'function' ) ? content.XMLHttpRequest  : window.XMLHttpRequest;
const fetch = ( typeof content != 'undefined'&& typeof content.fetch == 'function' ) ? content.fetch  : window.fetch;

のようにしておけばよいかも。

問題なのは、jQuery のようなライブラリを使用する場合で、作りによってはソースコードを直接書き換えるしか無いかもしれない。
なお、Firefox のアドオンを AMO にアップする際には、既知のライブラリを使う場合、改変されたものは同梱出来ない、という制約がある。レビューでチェックされ、改変が見つかった場合は当該バージョンが無効化されてしまう（経験済み(汗)）。

幸い、jQuery の場合には、読み込んだ後にjQuery.ajaxSettings.xhrを次のような感じにオーバーライドしてやればよいっぽい。

if ( ( typeof content != 'undefined' ) && ( typeof content.XMLHttpRequest == 'function' ) ) {
    jQuery.ajaxSettings.xhr = function () {try{returnnew content.XMLHttpRequest();
        }catch ( e ) {}};
}

失敗例

SPF レコードを

mydomain.com.          3600    IN      TXT     "v=spf1 ip4:XXX.XXX.XXX.XXX ~all"

mydomain.com.          3600    IN      TXT     "v=spf1 a:myaccount.sakura.ne.jp ~all"

mydomain.com.          3600    IN      TXT     "v=spf1 mx ~all"

といった様に、許容するIPアドレス／ドメインとして初期ドメインを設定してしまうと、認証に失敗してしまう（場合がある）。
ビジネスプラン等では、初期ドメイン（myaccount.sakura.ne.jp）とサーバーのホスト（wwwNNN.sakura.ne.jp）が示すIPアドレスが異なっているため、失敗(softfail)する。スタンダードプラン等では同じIPアドレスを示すので、結果的に通る(pass)場合もある。

例えば Gmail アドレス宛にメールを送付したとき、認証に失敗していると、メールヘッダで

ARC-Authentication-Results: i=1; mx.google.com;
       spf=softfail (google.com: domain of transitioning user@mydomain.com does not designate YYY.YYY.YYY.YYY as permitted sender)smtp.mailfrom=user@mydomain.com

のように SPF チェックの結果が "softfail"であったことが記載され、Gmail で当該メールを見たときに「未認証メール」として、「？」マークが付く。
メールを開き、「？」マークをタップ／マウスオーバすると、「Gmail では、このメールが（スパム発信者からではなく）本当に mydomain.com から送信されたメールであることを確認できませんでした。」といった文言が表示される。

試行環境

• Windows 10 Pro バージョン 1903（Microsoft Windows [Version 10.0.18362.535]）
• Git for Windows version 2.24.1.windows.2 （※手順はGit BASH上で実施）
• Node.js v12.14.1 LTS (npm 6.13.4)
• Yarn 1.21.1
• Yeoman / yo 3.1.1
• generator-chrome-extension-kickstart-typescripta5d5fc8 on 2 Sep 2017（※2020/01/11時点の最新版 ）

# Node.js v12.14.1 LTS および Yarn 1.21.1 は、それぞれインストーラをダウンロードしてインストール済
$ node -v&& npm -v
v12.14.16.13.4

$ yarn -v1.21.1# yo および generator-chrome-extension-kickstart-typescript を npm もしくは yarn にて global インストール#$ npm install -g yo generator-chrome-extension-kickstart-typescript
$ yarn global add yo generator-chrome-extension-kickstart-typescript

$ yo --version3.1.1

手順

1. 拡張機能用のプロジェクト作成

$ mkdir-p sample
$ cd sample
# --skip-install を付けて、npm による自動インストールを抑制
$ yo chrome-extension-kickstart-typescript --skip-install

2. package.json 編集

$ vi ./package.json

• "devDependencies"フィールド中、"gulp"のバージョンを "3.9.0"に固定
  3.9.1だと "Failed to load external module @babel/register" のような警告が出るからだが、その後 fallback されるため、このバージョンダウンは必須ではない
• 同フィールドに、"typescript" : "^3.x.x"を追加
  2020/01/11時点では Version 3.7.4 が入った
• "resolutions"フィールドを作成し、"gulp"下の "graceful-fs"のバージョンとして "^4.x.x"を指定
  Yarn の Selective dependency resolutions用設定

※差分例

--- ./package.json.orig 2020-01-11 14:33:14.473509100 +0900+++ ./package.json      2020-01-11 14:44:36.316563000 +0900@@ -32,7 +32,7 @@"chromereload": "0.x.x",
     "debounce": "1.x.x",
     "del": "3.x.x",
-    "gulp": "3.x.x",+    "gulp": "3.9.0","gulp-bump": "2.x.x",
     "gulp-cache": "0.x.x",
     "gulp-clean-css": "^3.x.x",
@@ -57,6 +57,10 @@"vinyl-named": "1.x.x",
     "webpack": "3.x.x",
     "webpack-stream": "3.x.x",
-    "yargs": "^8.x.x"+    "yargs": "^8.x.x",+    "typescript": "^3.x.x"+  },+  "resolutions": {+    "gulp/**/graceful-fs": "^4.x.x"
   }
 }

3. パッケージのインストール

$ yarn install

4. 動作確認

$ yarn run dev:chrome

※ 正常動作したときの例

yarn run v1.21.1
$ gulp --watch--vendor=chrome[14:56:00] Requiring external module babel-core/register
[14:56:07] Using gulpfile D:\webext\sample\gulpfile.babel.js
[14:56:07] Starting 'build'...
[14:56:07] Starting 'clean'...
[14:56:07] Finished 'clean' after 3.37 ms
[14:56:07] Starting 'manifest'...
[14:56:07] Starting 'scripts'...
[14:56:07] Starting 'styles:css'...
[14:56:07] Starting 'styles:less'...
[14:56:07] Starting 'styles:sass'...
[14:56:07] Starting 'pages'...
[14:56:07] Starting 'locales'...
[14:56:07] Starting 'images'...
[14:56:07] Starting 'fonts'...
[14:56:07] Starting 'chromereload'...
[14:56:07] Starting 'livereload-server'[14:56:07] Finished 'styles:css' after 32 ms
[14:56:07] Finished 'styles:less' after 26 ms
[14:56:07] Finished 'styles:sass' after 26 ms
[14:56:07] Starting 'styles'...
[14:56:07] Finished 'styles' after 20μs
[14:56:07] Finished 'pages' after 27 ms
[14:56:07] Finished 'fonts' after 26 ms
[14:56:07] Finished 'manifest' after 264 ms
[14:56:07] Finished 'locales' after 237 ms
[14:56:07] Finished 'images' after 237 ms
ts-loader: Using typescript@3.7.4 and D:\webext\sample\tsconfig.json
[14:56:10] Finished 'scripts' Hash: 941f7e8c10f53a4b8956
Version: webpack 3.12.0
Time: 2076ms
        Asset     Size  Chunks             Chunk Names
background.js  6.83 kB       0[emitted]  background
   [0] multi ./app/scripts/background.ts 28 bytes {0}[built][1] ./app/scripts/background.ts 254 bytes {0}[built][14:56:10] webpack is watching for changes

発生した不具合

最初に、qiita.comを参考にして、

$ mkdir-p sample
$ cd sample
$ yo chrome-extension-kickstart-typescript
# 試行のためとりあえず問にはすべて[Enter]
$ npm install --save-dev typescript
$ npm install --save-dev gulp@3.9.0
$ npm run dev:chrome

のようにしたところ、

$ npm run dev:chrome

> sample@0.0.0 dev:chrome D:\webext\sample
> gulp --watch--vendor=chrome[08:33:12] Requiring external module babel-core/register
fs.js:27
const { Math, Object }= primordials;
                         ^

ReferenceError: primordials is not defined
    at fs.js:27:26
    at req_ (D:\webext\sample\node_modules\natives\index.js:143:24)
    at Object.req [as require](D:\webext\sample\node_modules\natives\index.js:55:10)
    at Object.<anonymous>(D:\webext\sample\node_modules\vinyl-fs\node_modules\graceful-fs\fs.js:1:37)
    at Module._compile (internal/modules/cjs/loader.js:955:30)
    at Module._extensions..js (internal/modules/cjs/loader.js:991:10)
    at Object.require.extensions.<computed>[as .js](D:\webext\sample\node_modules\babel-register\lib\node.js:152:7)
    at Module.load (internal/modules/cjs/loader.js:811:32)
    at Function.Module._load (internal/modules/cjs/loader.js:723:14)
    at Module.require (internal/modules/cjs/loader.js:848:19)
npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! sample@0.0.0 dev:chrome: `gulp --watch --vendor=chrome`
npm ERR! Exit status1
npm ERR!
npm ERR! Failed at the sample@0.0.0 dev:chrome script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\testuser\AppData\Roaming\npm-cache\_logs\2020-01-11T06_33_12_337Z-debug.log

調査

Node.js v12 と gulp.js 3 は相性が悪いらしい?!

1. gulp.js を version 4 にする
2. Node.js のバージョンを v12 未満へ下げる

のいずれかで対応できるらしい。

1. の gulp.js のバージョンを変える方は、3→4 の変更に対応してソースコードも変更が必要になると思われるので手間がかかりそうだったため、2. の方法を試してみる。
nvm-windowsで Node.js のバージョンを 10.18.1 LTS にしてみると、確かに動作するようになった。

Node.js v12 ＆ gulp.js 3 のまま使いたいな……

要は、gulp.js が利用している graceful-fs のバージョンが古いのが悪いらしい。

$ npm list graceful-fs

で調べてみると、他はほとんどが "graceful-fs@4.2.3"を使っているのに対し、gulp（及び
gulp が依存しているパッケージ）については

+-- gulp@3.9.0
| `-- vinyl-fs@0.3.14|   +-- glob-watcher@0.0.6|| `-- gaze@0.5.2
|   |   `-- globule@0.1.0||     `-- glob@3.1.21
|   |       `-- graceful-fs@1.2.3|   `-- graceful-fs@3.0.12

のように、確かに古いバージョン（"graceful-fs@1.2.3"、"graceful-fs@3.0.12"）を使っている。

そういえば、yo chrome-extension-kickstart-typescript 実行時にも

npm WARN deprecated graceful-fs@1.2.3: please upgrade to graceful-fs 4for compatibility with current and future versions of Node.js

のような警告が出ていた。これによれば、graceful-fs 4 以降を使うようにすれば良さげ。

上記の記事を参考に、npm-shrinkwrap.json を

{"dependencies": {"graceful-fs": {"version": "^4.x.x"
     }}}

の内容で作成した後、改めて npm install 後に npm run dev:chrome をすると、

# package-lock.json は npm-shrinkwrap.json と排他なため、消しておく
$ rm package-lock.json
# パッケージのインストール
$ npm install
# ※このとき、npm-shrinkwrap.json も更新されることに注意# 開発環境を起動
$ npm run dev:chrome

すると、今度はエラーになると起動することができた。

ただし、この方法だと、

• npm install --save-dev でパッケージを入れたりすると、最初に指定した "dependencies"が維持されないため、再度 npm-shrinkwrap.json を上記内容に書き換えた上で npm install を実行しなおす必要がある

ということで、やや保守性に欠ける。

特定のパッケージが依存関係にあるパッケージだけバージョンを指定したい

• gulp が依存している graceful-fs のみ、バージョンを指定したい
• メンテナンスは最小限（意識するのは初回のみ）としたい（パッケージの追加時等に影響無いようにしたい）

となる。

調べてみると npm の代わりに Yarn を使用し、『選択的な依存関係の解決（Selective dependency resolutions）』機能を使えばできそう（package.json に "resolutions"フィールドを追加）。

"resolutions": {"gulp/**/graceful-fs": "^4.x.x"
  }

この方針で調整したのが、こちらの手順になる。

参考：npm で Yarn の "resolutions"っぽいことはできないか？

ただ、試してみた限りでは

• 階層指定（"gulp/**/graceful-fs"等といった書き方）はできない
• "scripts"セクションに"preinstall"を追加するのは、一度 npm install を実行後にする必要あり
  いったん npm install してから（package-lock.json が作成されてから）でないと、npm-force-resolutions がエラーになる
• パッケージの追加時等でpackage-lock.jsonが更新された際には、npm install をやり直す必要あり

のような感じで、今ひとつ使い勝手が良くないように感じた。
ざっくりとか見ていないため、誤解しているかもしれない

generator-chrome-extension-kickstart 及び主な fork の状況

• generator-chrome-extension-kickstart-typescriptは generator-chrome-extension-kickstartの fork（4.4.0 (7109375 on 3 Aug 2017)から）
• generator-chrome-extension-kickstartは TypeScript 対応版の fork 後も更新されている（最新版：b6d1067 on 9 Jan 2018、リリース最新：4.4.2 (5b8c0fa on 13 Oct 2017)）
• TypeScript 対応版（a5d5fc8 on 2 Sep 2017（※2020/01/11時点の最新版 ））が fork され、さらに Preactに対応した generator-chrome-extension-kickstart-typescript-preactもある（最新版：9caa42f on 23 Jan 2019）

A. 必要なコマンド毎に個別に winpty を付けて呼び出す alias を定義しておく

bash そのものを winpty 経由で呼び出しているのが原因なのでこれを止め、個別のコマンド毎に winpty 付き呼び出しを行うようにすれば問題はなくなる。
その場合、標準では /etc/profile.d/aliases.sh にて

for name in node ipython php php5 psql python2.7docase"$(type -p "$name".exe 2>/dev/null)"in''|/usr/bin/*)continue;;esacalias$name="winpty $name.exe"done

のように、いくつかのコマンドについて対応されているのを参考にして ~/.bashrc に必要なコマンドについて同様の記述を追記するというのが一つの方法。

B. 環境変数 PS1 を書き換える

A. のようにすると、対話型コマンドの種類が増えるごとにメンテナンスしなければならないため、面倒なのが難点。
bash を winpty で呼び出したときにウィンドウタイトルのみが化けているのが問題なので、プロンプト定義用の環境変数（PS1）を書き換えてやれば良いのではないか？　という発想。
状況的に、bash を winpty 経由にした際には、mintty はウィンドウタイトル文字列としては Shift-JIS(CP932) で渡されることを期待しているのではないか、と考えて、$PS1 中に含まれる $PWD の文字コードを変換するように定義してみると、

export PS1=`echo"$PS1"|sed"s~\\$PWD~\\\`echo \\$PWD | iconv -f utf-8 -t cp932 2>/dev/null\\\`~"`

うまくいった。
ウィンドウタイトルに関してだけはなんとかなったということで、winpty bash したときに出る潜在的な問題は他にもあるかも知れない。

覚え書きを兼ねて、現状の ~/.bash_profile および ~/.bashrc を残しておく。

~/.bash_profile

#【覚書】# ※参考：[bashの.profileや.bashrc等を実行する動作仕様 - sgryjp.log](https://blog.sgry.jp/entry/2019/11/09/232927)#===============================================================================# ・ ~/.bash_profile はログインシェルで一度だけ実行される#   このため、主に##   - ログイン時に一度だけ実行したい処理#   - 対話操作では必要のない（対話操作以外のコマンド実行に必要な）設定（環境変数 LANG 定義等）#   - ログインシェル／サブシェルに関わらず基本変更不要な設定（環境変数 PATH 定義等）##   を記述するのに向く## ・ ~/.bashrc はサブシェルでは自動的に呼ばれる（ログインシェルでは自動では呼ばれない）#   このため、~/.bash_profile からも呼び出されるよう設定の上で (^1)##   - alias や関数等、暗黙的に引き継がれない設定#   - 対話操作のみで必要となる設定（環境変数 PS1、EDITOR 等）##   を記述するのに向く##   (^1) ~/.bashrc があるのに ~/.bash_profile, ~/.bash_login or ~/.profile が無い環境は推奨されず、#        例えば Git for Windows においては、その場合、/etc/profile.d/bash_profile.sh により#        ~/.bashrc を呼び出す記述が入った ~/.bash_profile が生成される#===============================================================================# ■ ~/.bashrc 実行#   ※ログインシェルでは ~/.bashrc は自動的には実行されないため、この設定が必要#test -f ~/.profile && . ~/.profiletest-f ~/.bashrc && . ~/.bashrc

# ■ 各種定義export PYTHONUTF8=1export PYTHONSTARTUP=~/.pythonstartup

# ■ bash を winpty 経由で起動#   ※ Windows ネイティブな対話型コマンド（Python 等の、interactive mode が mintty に対応していないもの）に対応exec winpty bash
#   ※ exec によりシェルプロセス自体を置換しているため、これ以降に書いた内容は反映されないことに注意

~/.bashrc

if [[$TERM_PROGRAM="mintty"]];then# ■ mintty 専用設定case`tty`in
        /dev/cons*)# winpty# winpty 経由だと $PWD が日本語を含む場合ウィンドウタイトルが文字化けする（mintty 3.2.0）問題に対処export PS1=`echo"$PS1"|sed"s~\\$PWD~\\\`echo \\$PWD | iconv -f utf-8 -t cp932 2>/dev/null\\\`~"`;;
        /dev/pty*)# (default);;esacfi# ■ 暗黙的にサブシェルに引き継がれない設定（alias・関数定義）# ※サブシェルでは、#   - profile系スクリプト（/etc/profile、/etc/profile.d/*、~/.bash_profile等）は実行されない#   - ログインシェルで定義された alias や関数は引き継がれない#   ことに注意shopt-q login_shell || {# サブシェル専用設定# ※必要に応じて /etc/profile や /etc/profile.d/* （aliases.sh等）で定義されている alias 等をコピーしておくalias ls='ls -F --color=auto --show-control-chars'alias ll='ls -l'}# ~/.bash_profile 経由／サブシェル共用設定alias ls='ls -aF --color=auto --show-control-chars'alias tree='tree -N'alias python2='py -2'alias python3='py -3'alias python='python3'alias pip2='python2 -m pip'alias pip3='python3 -m pip'alias pip='pip3'# ■ 非対話ログインで不要かつ対話ログインで使いたい設定（環境変数定義）export EDITOR=vim

Evaluate all user-specific Bash completion scripts (if any)（Git BASH 独自仕様？）

• /etc/profile.d 下のファイルは通常はログインシェルからしか呼ばれないものだが、git-prompt.sh に限り、サブシェルからも呼び出される（/etc/bash.bashrc 経由）
• ~/bash_completion.d/ というディレクトリを作成し、この下に拡張子 .bash の付いた任意の bash スクリプトを置いておくと、/etc/profile.d/git-prompt.sh 経由で呼び出される（結果的にはログインシェル／サブシェルの区別なく呼ばれることになる）

winpty・mintty 関連

mseeeen.msen.jp

bash 関連ファイル（~/.bash_profile・~/.bashrc 等）の動作仕様について

blog.sgry.jp
なんとなくで設定しがちだった bash の ~/.bash_profile や ~/.bashrc といったファイルの動作仕様が分かりやすくまとまっていて非常に参考になった。

2020/04/01より前のサイトマップ仕様

2020/03/31まで、サイトマップの仕様は

/sitemap.xml?page=<ページ番号>

のような形式で、1ページ毎に作成日付の新しいものから順に100件ずつ、記事のURLと更新日付が含まれる仕様になっていました。
なお、当概仕様のサイトマップには現在でもアクセス可能です。
これだと、特定記事の更新日付を取得するためには、当該記事のURLが現れるまでひたすらページ番号を増やしてアクセスする必要があります。
上記の記事やコメント中でも、サイトマップから更新日を取得することは可能ではあるものの、記事と一致させることが手間なので実用的ではない旨書かれています。

このサイトマップを使った更新日付表示の実装例は
www.tsubasa-note.blog

等があるようです。
また、サイトマップの場合には何度もアクセスが発生してしまう問題を解消するため、AMP（更新日付が埋め込まれている）を利用した実装もあるようです。
psn.hatenablog.jp

2020/04/01 以降のサイトマップ仕様

2020/04/01から配信されるようになったサイトマップの仕様では、

/sitemap_periodical.xml?year=<作成年>&month=<作成月>

のようにすると、

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"><url><loc>https://memo.furyutei.work/entry/20161015/1476495230</loc><lastmod>2016-12-06T09:08:18+09:00</lastmod></url><url><loc>https://memo.furyutei.work/entry/20161008/1475863694</loc><lastmod>2016-12-06T09:08:56+09:00</lastmod></url><url><loc>https://memo.furyutei.work/entry/20161008/1475860031</loc><lastmod>2017-11-14T07:08:24+09:00</lastmod></url><url><loc>https://memo.furyutei.work/entry/20161007/1475839249</loc><lastmod>2020-03-07T03:29:59+09:00</lastmod></url></urlset>

のように、指定した年月に作成した記事のURLと更新日の一覧を取得することが出来るようになっていました。
これならアクセスが1回だけで済むので、実用的だと思われます。

注意事項

• スクリプトをブログのフッタなどに貼り付ける場合、<script>～</script>で囲むのを忘れないこと
• サンプルソースコードはGist上にあります。なお、残念ながら Gist 上のコードは外部スクリプトとしては読み込めません（Content-Type: text/plain; charset=utf-8 のため）
• async/await とか使っているので、モダンブラウザじゃないと動きません(笑)
  それじゃ嫌だというかたはこちらの記事等を参考にして、新しいサイトマップ仕様に対応させてみてください

ソースコード

更新日付と警告用スクリプト（ブログのデザイン→カスタマイズ→フッタへの貼り付け用）

更新日付と警告用CSS（ブログのデザイン→カスタマイズ→デザインCSS貼り付け用）

サンプルコード

対策

1. リボンの「ファイル」メニューから、「オプション」→「トラスト センター」で [トラスト センターの設定 (T) ...] をクリック
2. 「信頼できる場所」の [新しい場所の追加 (A) ...] で、当該ワークシートを置いてあるフォルダを指定する（必要に応じて、「□ この場所のサブフォルダーも信頼する (S)」にもチェックを入れておく）

注意事項

• 同様の環境であっても、現象が再現しない場合もあります
  自分のところでも、同じファイルを、別の PC 上で試しても（「信頼できる場所」に置いていないにも関わらず）特に重くなりませんでした。また、同一 PC 上であっても、ファイルの内容によっては（？）再現しない場合もあるようです。
• 上記の対策は、マクロのセキュリティ関連の設定になるため、「信頼できる場所」に追加するフォルダについては慎重に検討するようにしてください。試して見る場合には自己責任でお願いします。
• あくまで当方個人の環境での対策のため、同様の現象が発生していて対策通りの手順を踏んでも改善されない場合もあるかと思いますが、ご容赦願います。

フォローしている方のFleet画像／動画のダウンロード方法

[Twitterのホームタイムライン](https://twitter.com/home)を開くと、上部に[Fleets 💾]のようなボタンが表示されます。

これをクリックすると、フォローしている方が公開中のFleet画像／動画をまとめて（ZIPファイルで）ダウンロードできます。
また、[Alt]+クリックで、画像／動画を別タブでまとめて開くこともできます。
ブラウザのポップアップブロックにより別タブでうまく開けない場合は、ポップアップブロックをオフにするか、あきらめてください。

ユーザーが公開中のFleet画像／動画のダウンロード方法

ユーザーのプロフィールタイムラインを開くと、その方がFleetを公開中であれば、プロフィールアイコンの周りが水色になり、同時に[Fleets 💾]のようなボタンが表示されます。

これをクリックすると、その方が公開中のFleet画像／動画をまとめて（ZIPファイルで）ダウンロードできます。

こちらも、[Alt]+クリックで、画像／動画を別タブでまとめて開くこともできます。
注意書きも同上です。

元ツイートが「.work」ドメインの記事を含む場合

「.work」ドメインの記事を引用してツイートした場合、そのツイートにリプライが付くと、元ツイートを開いたらリプライツイートも表示されます。
ここまではいいのですが、実は、

• リプライツイート（およびリプライツリーで繋がったツイート）を開くと、（自分以外のユーザーからは）元のツイート（リプライ先・「.work」ドメインの記事を引用したもの）は見えず、「このツイートは表示できません。（This Tweet is unavailable. ）」状態となってしまう
  これ、自分で見る分には普通に表示されるため、誰かに指摘されたりしないと気が付かない罠

という不具合が発生します。

このツイートは表示できるのに、https://t.co/oHeMAVi3qL

ぶら下がっているツイートから見ると「表示できません」と表示される。https://t.co/RPeNPzfywo

不思議です・・・。 pic.twitter.com/kwElBRjxi2

— はけた＠経理のExcel仕事術 発売中 (@excelspeedup) 2020年11月17日

元ツイートで記事を引用し、これにリプライがついたときに、第三者がリプライツイートを開いた場合の表示例。

1枚め：「.work」ドメインで引用
2枚め：「.work」ドメイン以外（はてなブログのURL）で引用 https://t.co/NtEORNBTQ4pic.twitter.com/bAK2nLzMsZ

— 風柳 (@furyutei) 2021年2月10日

リプライツイートが「.work」ドメインの記事を含む場合

また、Twitter のツイートに対するリプライ中に「.work」ドメインの記事（URL）を引用してしまうと、

• 元ツイートのユーザーには通知が行かない
• （自分以外のユーザーが）元ツイートを表示しても、「.work」ドメインの記事を引用したリプライツイートは見えず、リプライ数としてもカウントされない
  この場合も、自分で見る分には普通に表示されているので気が付きにくい
• 当該リプライツイートにさらにリプライが付いた場合、当該ツイートは「このツイートは表示できません。（This Tweet is unavailable. ）」状態となってしまう
  もちろん自分では普通に見える

という不具合が発生してしまいます。
なお、 （自分以外のユーザーであっても）当該リプライツイートを直接URLを指定して開けば見ることはできます。

例）https://t.co/7iYIhtvq7L
にぶら下がったhttps://t.co/AIbpVimaV7
のツイート、自分で見たときは表示されているのに（1枚目）、他の人からは「このツイートは表示できません。」となっていて見えない（2枚目）。
なお、リプライツイートのURLを直接表示した場合には他の人からも見える（3枚目）。 pic.twitter.com/5ytBSJhFws

— 風柳 (@furyutei) 2020年12月3日

他の人が引用したらどうなるのでしょうね。https://t.co/2RavTtpB3C

— OHNO Yousuke (@o_noyou) 2021年2月10日

・コメント先ユーザー（今回は私）宛の通知が来ない
・リプライのURLを直接開けばツイートは表示される
・リプライ先のツイートを表示すると、リプライツイートは見えず、コメントマークのところの数字も出ない

のようになりました。 pic.twitter.com/QKNg7QGCiZ

— 風柳 (@furyutei) 2021年2月10日

ちなみに、第三者から見るとこんな感じです。@o_noyouhttps://t.co/t0NZAnxWY5pic.twitter.com/aezwt2LlaZ

— 風柳 (@furyutei) 2021年2月10日

自分のところだけではないらしい

最初、自分のところだけかと思いましたが、gTLD「.work」を使っているサイトを3か所ほど探して試してみたところ、いずれも同様の不具合が発生していたので、少なくとも「.work」に関しては普遍的に発生するのではないかと予想しています。
他の TLD で同様の不具合が発生するかどうかまでは調べられていません。
「.work」は新gTLDと呼ばれる比較的歴史の浅いものらしいですが、そういうのが関係していたりするのですかね？