hogashi.*

日記から何から

GitHub ActionsでJestのログに色をつけられる

JavaScript GitHub Jest

That’s why we are increasing the color support, including:

  • ANSI colors
  • 8-bit colors
  • 24-bit colors
https://github.blog/2020-09-23-a-better-logs-experience-with-github-actions/#opening-the-door-to-a-more-colorful-experience

　ということは、 GitHub Actions で Jest の実行時に色つきログの指定をすれば、色つきで見ることができるようになる。どのテストが落ちているのかとか、ここで落ちましたというコード自体とかが見やすくて便利。

色がついたJestのログ
追記

　テストが落ちたときのアノテーションを diff の画面につける GitHub Actions Reporter の機能は Jest にもついているので、どこが落ちたか自体はそっちで見れるという話はある https://jestjs.io/blog/2022/04/25/jest-28#github-actions-reporter 。今回書いたのはログ自体を見たいとき便利というくらい。

GitHub Actions test error screenshot

https://jestjs.io/blog/2022/04/25/jest-28#github-actions-reporter
追記2

　興味を持った同僚がどんどん集まって色々見てくれて、

という感じで難しそうな局面だった。どうしても今すぐ Chalk 経由で GitHub Actions 上で色がつくように Jest を対応させたかったら、 Chalk v5.2.0 の色つける変更を Chalk v4 にバックポートするみたいになるのかな……。

拡張機能「twitter画像原寸ボタン」v4.2.0公開

拡張機能 GoogleChrome MSEdge

chrome.google.com

Microsoft Edge 版: twitter画像原寸ボタン - Microsoft Edge Addons

　拡張機能「twitter画像原寸ボタン」の v4.2.0 を公開しました (ボタンを押して審査中なので数日くらいで公開されるはず)。 Manifest V2 終了対応の準備リリースで、特に機能は変わりません。 localStorage に設定内容を保存していたのを chrome.storage に移し替える変更で、新しく storage 権限が必要になって追加したので、「エラー」とか出てそれを許可するか聞かれるかも (もし出たら、許可してもらえれば使えます)。

　追伸: v4.1.0 の記事書き忘れてた。画像が 4枚ある場合に Original ボタンを押した際、 2枚目と 3枚目の順番が逆だったのを修正しました (Chrome Web Store にフィードバックもらっていたのに見逃していてすみません)。以前はなぜか Twitter 公式 Web の (DOM の) 順番的に 1, 3, 2, 4 となっていたので入れ替えて開いていたんですが、最近ちゃんと公式で 1, 2, 3, 4 に変わったみたいです。尊い変更ですね。

developer.chrome.com

　ここから 1〜数ヶ月くらいして大丈夫そうだったら Manifest V3 に更新するかな〜という展開 (前に別の拡張機能で練習は済んでいた *1 けど元気がでなくて置いていた)。ちなみに本当は 2023/1 には MV2 は新規に submit できなくなる予定だったのが、 Service Worker への移行が大変という拡張機能開発者の声によりスケジュール未定 (2023/3 までには何か決めるらしい) となっています。とはいえすでにだいぶサボっていてギリギリではあるので早めにやっておきたい。

For this reason, we’re postponing any January experiments to turn off Manifest V2 in pre-release channels of Chrome and changes to the featured badge in the Chrome Webstore, and we'll be evaluating all downstream milestones as well. Expect to hear more about the updated phase-out plan and schedule by March of 2023.

https://groups.google.com/u/0/a/chromium.org/g/chromium-extensions/c/zQ77HkGmK9E?pli=1

groups.google.com

　追記: そういえば ESLint と Prettier と TypeScript と Jest の感じがうまくいかなくて厳しかったので、 linter/formatter は Rome にしてしまった。 VSCode 上での format on save も動くし特に困っていない。

*1:https://blog.hog.as/entry/2022/01/01/222853

aタグで#topにリンクするとページ先頭にスクロールするのは仕様

HTML CSS JavaScript

　はてなエンジニア Advent Calendar 2022 - Hatena Developer Blog の 2023/1/5 の記事です。 id:hogashi です。

目次
3行
  • a タグの href 属性に #top と書くと、クリックしてページの先頭にスクロールできる、という話をしているのを見て、
  • それって仕様なんだっけ、と思って調べたところ、
  • 仕様でした
こういうやつ

クリックしてこのページの先頭にスクロールする

<a href="#top">クリックしてこのページの先頭にスクロールする</a>
仕様を眺める

　MDN の a タグのページにちょろっと書いてあって、 HTML の仕様に定義されているよ、とある <a>: The Anchor element - HTML: HyperText Markup Language | MDN 。

Note: You can use href="#top" or the empty fragment (href="#") to link to the top of the current page, as defined in the HTML specification.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#linking_to_an_element_on_the_same_page

　リンク先はここ https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier で、 "Scrolling to a fragment" という仕様。パーセントデコードした fragment が top という文字列だったら、 "top of the document" が指定されることになっている。つまり a タグじゃなくても、 URL に #top と書いたらページ先頭にスクロールできる。
　追記: ただし id="top" な要素がある場合は、そちらにスクロールされます。これは手順の上で先に採用されるためで、この記事の最後に詳しく追記しました。

If decodedFragment is an ASCII case-insensitive match for the string top, then return the top of the document.

https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier

　"top of the document" のときどうなるかは https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment:top-of-the-document に書かれていて、ページの先頭にスクロールするようになっている。

Otherwise, if document's indicated part is top of the document, then:

  1. Set document's target element to null.

  2. Scroll to the beginning of the document for document. [CSSOMVIEW]

  3. Return.

https://html.spec.whatwg.org/multipage/browsing-the-web.html#scrolling-to-a-fragment:top-of-the-document

　"Scroll to the beginning of the document" の部分は CSS の仕様 https://drafts.csswg.org/cssom-view/#scroll-to-the-beginning-of-the-document にリンクされていて、その document の viewport のスクロール位置を先頭にするみたいな手順が書かれていて細かくてすごい。その document のということは、 iframe で表示しているときなどは、そのフレーム内の先頭へのスクロールになるわけですね。

　ちなみに HTML での #top の挙動で使われる仕様ですみたいなことが端書きされていて丁寧。

Note: This algorithm is used when navigating to the #top fragment identifier, as defined in HTML. https://drafts.csswg.org/cssom-view/#scroll-to-the-beginning-of-the-document
追記1:

　この記事を見てもらっていたようなのですが、確かにフォーカスなど他の挙動は全く見ていませんでした。 #top のときページの先頭にスクロールする仕様自体、古いブラウザの実装を互換性のために HTML の仕様に入れているのでは、という話もあるので、この仕様を積極的に利用していくことはあまり推奨されないかもしれません (つまり先頭に戻る用の要素を別途置くのがよい)。

おまけ

　ちなみに 「a top MDN」みたいな検索キーだと、今回の話題が全然ヒットしなくて難しかった (CSS の top とか window.top とかが出てきてしまう) ですが、 a タグは「anchor」にしたり、記号込みで完全一致させるために「"#top"」としたりするとうまいことヒットする感じでした。僕はあんまりうまくいかなくて && a タグのページに記述があるの見逃してて、色々試したら stackoverflow が出てきて MDN へのリンクをゲットできた……(たどり着けているので良い)。

　ちなみに2、 window.location.hash が変わったときは hashchange イベントが発火して便利 Window: hashchange event - Web APIs | MDN 。今回の記事の iframe 部分の URL 表示に使って初めて知りました。

追記2: id="top" な要素があるときは？

　ブコメで予約語という単語を見て、たしかに id="top" なタグを書くとどうなるのか？？？ と思って glitch で試しました。id="top" なタグにスクロールされます。

　これは、仕様でいうところの indicated part を決める手順において、そういう要素が見つかったときはそっちが先に採用されるためです (手順4で終了するパターン。先頭に戻るのは手順9)。上のほうではこの手順のひとつだけを抜粋してしまったので紛らわしかったですね……。

For an HTML document document, the following processing model must be followed to determine its indicated part:

  1. Let fragment be document's URL's fragment.

  2. If fragment is the empty string, then return the special value top of the document.

  3. Let potentialIndicatedElement be the result of finding a potential indicated element given document and fragment.

  4. If potentialIndicatedElement is not null, then return potentialIndicatedElement.

  5. Let fragmentBytes be the result of percent-decoding fragment.

  6. Let decodedFragment be the result of running UTF-8 decode without BOM on fragmentBytes.

  7. Set potentialIndicatedElement to the result of finding a potential indicated element given document and decodedFragment.

  8. If potentialIndicatedElement is not null, then return potentialIndicatedElement.

  9. If decodedFragment is an ASCII case-insensitive match for the string top, then return the top of the document.

  10. Return null.

https://html.spec.whatwg.org/multipage/browsing-the-web.html#scroll-to-the-fragment-identifier

脆弱性情報に誤記があるとき問い合わせると修正してもらえる

脆弱性 AdventCalendar

目次

　こんにちは、 id:hogashi です。 はてなエンジニア Advent Calendar 2022 - Hatena Developer Blog の 30日目の記事です。昨日は id:stefafafan さんの
はてなのエンジニアとして日々意識しながらやっていることを紹介します - stefafafan の fa は3つです でした。年の瀬MAXですね。

　僕は業務でセキュリティ会というものに参加していて、毎週の定例で脆弱性情報を眺めています。脆弱性情報、特に CVE Record などにはなんとなく正確さを期待しますが、人間が運用している以上ミスはあるもので、たまに typo など誤記があることもあります。
　そういうものに気づいたときには、修正してもらえるよう問い合わせてみたりしています。よく見ると問い合わせフォームがあったりメールアドレスが案内されていたりするので、そこにこんにちは〜と問い合わせることは、気持ちとしては GitHub で issue を立てることと似たようなことか、と思っています。

実際の例

NVD

nvd.nist.gov

　CVE-2022-25521 の description は NUUO v03.11.00 was discovered to contain access control issue. ということで、 NUUO という製品に脆弱性がありました。しかし、元の description は UNNO v03.11.00 was discovered to contain access control issue. となっていました (NUUO ではなく UNNO となっている)。ちなみに変更履歴は、ページの下の方の「Change History」から「show changes」を押すことで見られます。
　reference も同様に http://unno.com となっていましたが、これにアクセスすると自転車メーカのサイトが表示され、まずアレッとなります。次にもうひとつの reference である Medium のページを見ると、 Use of Default Credentials to Unauthorised Remote Access of Internal Panel of Network Video recorder of NUUO となっており、 Vendor Homepage も https://nuuo.com/ と書かれていたため、 CVE 情報の typo を確信しました。

　さて、ここで初めての NVD に対する問い合わせをしました。フッタにある「Contact Us」からできます: Contacting NIST | NIST 。脆弱性番号と、見た URL 、どこが間違っていてどうなっているべきか (UNNO じゃなくて NUUO 、 http://unno.com じゃなくて https://nuuo.com/)、などを書いてフォームを送信しました。当時は (メールを見る限り) 「CVE Configuration Update Request」というのをプルダウンから選んで送ったようですが、今はフォームが新しくなっていて*1、選択肢が変わっていました (どれで送るのがいいのかわからないときは General Questions にしておけば受け取ってもらえそう)。

　数日ほどして、「ありがとう、 configuration は変えました。ただ description や reference のリンクなどは CVE Assignment Team のほうに問い合わせてね、 https://cveform.mitre.org/ からできるよ」というような返信がメールでもらえました。めちゃくちゃ丁寧。 NVD の変更履歴を見る限り、 configuration というのは CPE Configuration というもののようです。

CVE

cve.mitre.org

　というわけで大本の CVE 情報を直してもらうべく、 NVD 同様フッタの「Contact Us」から送りました: https://cveform.mitre.org/ 。大体同じ内容で書きましたが、 PGP key を入れる欄があったのは面白かったです (生成して送りましたが、今回は脆弱性を発見/報告したわけではなかったので？別に使いませんでした)。

　こちらも「ありがとう、レビューするね」というお返事が来ました。 NVD の変更履歴を見る限り、かなり素早く修正されていそうですね (ありがたい)。

番外編: Security NEXT

www.security-next.com

　脆弱性について記事を公開しているサイトです。下の方に書かれている通り、アップデートされたバージョン番号が 2021.005.20148 となっていたのに対して、 Adobe の情報を見ると 2021.005.20048 となっていたので、フッタの 運営会社：Security NEXT からメールを送りました。
　Security NEXT編集部さんから「記事公開当時の Adobe の情報がそうなっていたためで、たしかにそう更新されていたので修正しました、ありがとうございました」というお返事をもらい、なるほどそういうことがあるのか、という体験でした (たしかに Adobe のページをよく見るとそういう変更履歴が書かれていました)。

むすび

　脆弱性情報について、なんか間違えてそうだね、という話をするだけのことがほとんどだったのですが、情報が正しくなれば脆弱性の対応もしっかりできることになるので、気づけたときにはこういった調子で問い合わせフォームから伝えてみているのでした。

　はてなエンジニア Advent Calendar 2022 - Hatena Developer Blog 、明日は id:tkzwtks さんです。

*1:今回のことで迷惑をかけてしまっていないことを祈りたい

ブラウザで:has()セレクタが実装されてjQueryの:has()セレクタの挙動が変わった話の続き

CSS HTML JavaScript

前回までのあらすじ

blog.hog.as

　ブラウザで :has() を実装した結果、 :querySelectorAll() で :has() を扱えるようになり、 jQuery で :has() を使ったときの挙動が変わってしまっていた。

その後

　結局、 :is :where 以外のセレクタ (含む :has()) を unforgiving にすることが決まっていた。 :is :where だけは forgiving なままとするので、 :has(:is(ほげほげ)) と書くと forgiving な使い方にすることもできる、という態度っぽい (pull request のテストケースで言うと、 :has(:is(.a, 123)) は (123 が invalid なセレクタなので) :has(:is(.a)) として扱われる)。

　Chrome を見ると、 Make :has() unforgiving (Ibb499e25) · Gerrit Code Review とかで実装もマージされていそうに見える。 Chrome のリリースまでの流れに詳しくないけど、近いバージョンで出てきそう？ (そのタイミングで jQuery の挙動も戻りそう？)