Hello, Javan Makhmali here
…and there ↝ Twitter, GitHub, javan@javan.us

  1. twitter.com/javan/status/1388215254685990915
  2. bugs.webkit.org/show_bug.cgi?id=222657

    Bug 222657 — Media element never populates its UA shadow if it was initially created in a document without browsing context

     
    Created attachment 422090
Test case

When input and media elements are adopted with document.adoptNode() from a foreign document (via DOMParser, for example) they lose their native shadow DOM roots and are left in a mostly broken state: <input>s lose their native UI, and <video> and <audio> elements lose their native controls.

To reproduce, open the attached adopt-node-bug.html file in Safari and compare the correct middle column (imported node) to the incorrect right column (adopted node).

Tested in Safari v14.0.3 (16610.4.3.1.4) on macOS v11.2.2, and mobile Safari on iOS v14.4.
  3. github.com/electron/electron/issues/26946
  4. youtube.com/watch?v=hdiLqJc0ySc
  5. github.com/rails/rails/issues/39291
  6. bugs.webkit.org/show_bug.cgi?id=211620
  7. bugs.chromium.org/p/chromium/issues/detail?id=1043564#c7

    Re: Bug 1043564 — Incorrect range calculated during a 'deleteSoftLineBackward' event

     
    Here is another example that demonstrates the issue. It works by canceling the "beforeinput" event and applying the target range to the selection to illustrate it.

1. Open the attached "select-target-range.html" file in Chrome
2. Place the cursor at the end of each line and press Cmd+Delete
3. Observe the selection, which represents the target range
4. Not that it doesn't match the actual range of text to be removed
  8. bugs.webkit.org/show_bug.cgi?id=203116

    Bug 203116 — Native text substitutions interfere with HTML <datalist> options resulting in crash

     
    Created attachment 381204
Minimal test case to reproduce <datalist> crash

To reproduce:

1. Open System Preferences → Keyboard → Text and add entry to replace "cat" with "Cat"
2. Open the attached datalist.html file in Safari
3. Ensure that the menu option for Edit → Substitutions → Text Replacement is selected
3. Type "cat" in the text field and wait for the "Cat" replacement overlay to appear
4. Click any option from the expanded <datalist> menu and Safari will crash


Tested on macOS 10.14.6 (18G103) with Safari 13.0.2 (14608.2.40.1.3) and Safari TP Release 94 (Safari 13.1, WebKit 14609.1.6.1). I believe this issue occurs in Safari 12.1 as well.
  9. weblog.rubyonrails.org/2019/8/15/Rails-6-0-final-release/

    Rails 6.0: Action Mailbox, Action Text, Multiple DBs, Parallel Testing, Webpacker by default, and Zeitwerk

    Dealing with incoming email, composing rich-text content, connecting to multiple databases, parallelizing test runs, integrating JavaScript with love, and rewriting the code loader. These are fundamental improvements to the fundamentals of working with the web and building fast and fresh applications. This is the kind of work we’ve been doing for the past fifteen years, and we’re still at it. THIS IS RAILS SIX!

  10. bugs.chromium.org/p/chromium/issues/detail?id=992862

    Bug 992862 — Cutting from a contentEditable element causes slow forced reflow

     
    UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36

Steps to reproduce the problem:
1. Open the attached cut.html file and click "Cut All" (or, use the Edit → Cut menu)

What is the expected behavior?
The cut operation completes in a reasonable amount of time.

What went wrong?
The cut operation takes several seconds to complete. The Performance inspector reveals a very slow Layout task. See the attached .gif for a comparison by browser.

Chrome: 5,177ms
Firefox: 19ms
Safari: 147ms

Did this work before? N/A 

Does this work in other browsers? N/A

Chrome version: 76.0.3809.100  Channel: stable
OS Version: OS X 10.14.6
Flash Version:
  11. devchat.tv/js-jabber/jsj-376-trix-a-rich-text-editor-for-everyday-writing-with-javan-makhmali/

    JSJ 376: Trix: A Rich Text Editor for Everyday Writing with Javan Makhmali | Devchat.tv

    Today’s guest is Javan Makhmali, who works for Basecamp and helped develop Trix. Trix is a rich text editor for the web, made purposefully simple for everyday use instead of a full layout tool. Trix is not the same as Tiny MCE, and Javan discusses some of the differences. He talks about the benefits of using Trix over other native browser features for text editing. He talks about how Trix has simplified the work at Basecamp, especially when it came to crossing platforms. Javan talks more about how Trix differs from other text editors like Google Docs and contenteditable, how to tell if Trix is functioning correctly, and how it works with Markdown.

  12. twitter.com/javan/status/1151914387428564992
  13. github.com/github/eventlistener-polyfill/pull/13
  14. twitter.com/javan/status/1111329710842101760
  15. remoteruby.transistor.fm/31

    Joined by Javan Makhmali and Sam Stephenson | Remote Ruby

    Buckle up! In this episode, Javan Makhmali and Sam Stephenson join Jason and Chris. Sam and Javan are employees at Basecamp and also part of the mastermind behind many JavaScript libraries to come out of Basecamp: Turbolinks, Trix, and Stimulus. They each share how they got started programming, a brief insight into how they work at Basecamp, the transition from CoffeeScript to ES6, Typescript, as well as (wait for it...) upcoming features in Stimulus (🙌) and considerations for Turbolinks 6 (no feature promises made 😉). It was an absolute joy to chat with Javan and Sam. We very much enjoyed this episode and hope you will enjoy it, too.

  16. github.com/electron/electron/issues/16418
  17. github.com/basecamp/trix/pull/580
  18. 5by5.tv/rubyonrails/247

    Ruby on Rails Podcast #247

    Action Text is a new framework coming to Rails 6 to make it easier to create, edit, and display rich text content within an app. Brittany invited Javan Makhmali, programmer at Basecamp, on to the show to get the scoop.

  19. twitter.com/javan/status/1057247269307727872
  20. twitter.com/javan/status/1044958902369103874
  21. github.com/electron/electron/issues/14529
  22. twitter.com/javan/status/1027642135712018437
  23. github.com/basecamp/trix/pull/523
  24. github.com/basecamp/trix/pull/516
  25. twitter.com/javan/status/1012351745043902464
  26. bugs.webkit.org/show_bug.cgi?id=6656#c18

    Re: Bug 6656 — Image loading continues when IMG elements or Image JavaScript objects are removed

     
    Hello, another Basecamp developer here with more details.

We use `MutationObserver` to detect when images are added to the DOM and swap their "src" attribute with a tiny placeholder image. Then we restore the original "src" as images are scrolled into the viewport. This technique is commonly referred to as “lazy loading” and is intended to avoid unnecessary network requests for images that may never be viewed.

Due to this WebKit issue, our approach doesn’t work in Safari because the original image is always loaded.

Additionally (this may be a separate issue), cloning <img> elements causes them to load *again* even if the cloned node is detached from the DOM. For example, running `document.body.cloneNode(true)` reloads all of its images. This affects our Turbolinks (https://github.com/turbolinks/turbolinks) library, which stores “snapshots” of pages by cloning them.

I made a video to help illustrate the problem: https://www.youtube.com/watch?v=p6bkcjoyP1M

In Safari (left), every image on the page is loaded initially, and then loaded again when scrolled into view. Cloning <body> loads all of its images once more.

In Chrome (right), only the first image loads initially and the rest are canceled. Cloning <body> makes no additional network requests.

My example application and its source code are available here: https://glitch.com/~jealous-moon

Thanks for your time!
  27. github.com/rails/rails/pull/32967
  28. github.com/johnbeatty/trix_emoji/pull/1
  29. twitter.com/javan/status/984114017194168320
  30. twitter.com/javan/status/980842276850143233
    Javan Makhmali Javan Makhmali @javan View on Twitter

    🙃 Keepin’ it simple. Server-rendered client-rendered apps using a server-side client. twitter.com/ebidel/status/…

    Eric Bidelman Eric Bidelman @ebidel

    "Headless Chrome: an answer to server-side rendering JS sites": developers.google.com/web/tools/pupp… "...Headless Chrome eats JS for breakfast..." 🥞 New post on using headless/Puppeteer on the server to prerender dynamic pages for 1st load perf 📊, crawlers 🕸, social widgets 🗣, & more.

  31. github.com/electron/electron/issues/12366
  32. twitter.com/javan/status/966360950562582528
  33. bugs.chromium.org/p/chromium/issues/detail?id=764439#c9

    Re: Bug 764439 — composition event should be triggered on setComposingRegion

     
    Hello,

I’m one of the maintainers of Trix (https://github.com/basecamp/trix), a rich text editor for the web. Trix, like many modern editors, listens for events to record input, and then converts that input into an editing operation on its internal document model. This process has always been challenging on Android due to its lack of key codes on keyboard events (this ol’ issue https://bugs.chromium.org/p/chromium/issues/detail?id=118639), but we’ve managed well enough by handling composition events.

The change that fixed this issue is a significant departure from the current behavior of composition events, and problematic in a number ways:

1. Composition events are dispatched every time you move the cursor but aren’t typing. 

This alone quite a stretch from from the spec’s definition: “Composition Events provide a means for inputing text in a supplementary or alternate manner than by Keyboard Events” (https://www.w3.org/TR/uievents/#events-compositionevents). These composition events while moving the cursor also have no associated keyboard or inputs events, another deviation from the spec: “During the composition session, keydown and keyup events MUST still be sent” (https://www.w3.org/TR/uievents/#events-composition-key-events).

2. The DOM selection during compositions now varies depending on the context.

When moving the cursor, the selection during compositionupdate is always collapsed at the cursor’s position. When typing, the selection is the expanded range around the composed characters. This means we can’t reliably determine if the input is new or if it’s replacing a range of existing content.

Description of the attached screenshots:

cursor-movement.png: Shows the composition events dispatched after moving the cursor from left to right four times. Note how the compositionupdate data is identical, but the DOM selection is not.

movement-then-typing.png: Shows the events dispatched when placing the cursor before "The", "quick", and "brown", and then typing "fox " at the end. This illustrates how the selection expands while typing, and how difficult it is to distinguish input from cursor movement generally.

These screenshots come from http://jsfiddle.net/javan/mj13jj7b/embedded/result,js/ - a small test bed I made.

Related issue: https://bugs.chromium.org/p/chromium/issues/detail?id=812674

Thanks for your time!
  34. bugs.chromium.org/p/chromium/issues/detail?id=810895

    Bug 810895 — Programmatically focusing sticky positioned input elements incorrectly scrolls the page

     
    UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36

Steps to reproduce the problem:
1. Open the attached HTML file
2. Scroll to the bottom
3. Click each of the links to focus the form controls

What is the expected behavior?
The page does not scroll

What went wrong?
The page scrolls to the element's unstuck position when calling its focus() method.

This happens for all form controls except for <input type="text"> so https://bugs.chromium.org/p/chromium/issues/detail?id=740417 could be partially related.

Did this work before? No 

Does this work in other browsers? Yes

Chrome version: 64.0.3282.140  Channel: stable
OS Version: OS X 10.13.3
Flash Version: 

https://bugs.chromium.org/p/chromium/issues/detail?id=805800 may also be related.
  35. github.com/hotwired/stimulus/pull/61
  36. weblog.rubyonrails.org/2017/8/15/three-new-committers/
  37. github.com/rails/activestorage/pull/81
  38. bugs.webkit.org/show_bug.cgi?id=174165

    Bug 174165 — DataTransfer shouldn't contain text/html when performing Paste and Match Style

     
    Created attachment 314620
Paste event clipboard data inspector

The ClipboardData for paste events are identical when performing Paste (⌘V) and Paste and Match Style (⌥⇧⌘V). Because they're indistinguishable, it's impossible to programmatically handle pastes correctly in a rich text editor (like https://github.com/basecamp/trix, which I help maintain). There's no way to infer the desired format and pick an appropriate type.

To reproduce, open the attached paste-inspector.html file in Safari and paste as instructed. Note that the logged paste events are identical and both contain "text/html" and "text/plain" types. Chrome and Firefox only return a "text/plain" type when performing Paste and Match Style, which I assume is correct.

This issue is also present in previous versions of Safari.

Screenshots
Safari: https://cl.ly/291S1I3L2B25
Chrome: https://cl.ly/3m3B1P0D0Q2E
Firefox: https://cl.ly/3M3v2R2r2T2H
  39. github.com/electron/electron/issues/9717
  40. github.com/electron/electron/issues/9233
  41. github.com/puma/puma-dev/pull/101
  42. bugzilla.mozilla.org/show_bug.cgi?id=1332924

    Bug 1332924 — [contenteditable] Custom or inline element duplicated when deleting selection that spans different block element types

     
    Created attachment 8829246
ff-element-duplicated.gif

Steps to Reproduce:

1. Paste the following Data URI into your address bar:

   data:text/html;charset=utf-8,<x-foo contenteditable><div>ab</div><p>cd</p></x-foo>

2. Place the cursor before "b" and select through "c" so that both letters are selected

3. Press backspace


Expected Results:

<x-foo contenteditable>
  <div>ad</div>
</x-foo>

Actual Results:

<x-foo contenteditable>
  <div>a</div>
</x-foo>
<x-foo contenteditable>
  <p>d</p>
</x-foo>

Additional details:

Enabling dom.webcomponents.customelements.enabled and registering the element with document.registerElement has no affect.

The same problem is reproducible using <span contenteditable> as the containing element (instead of <x-foo contenteditable>) so I suspect Firefox treats the contained elements as invalid block children of an inline parent. Styling the container with "display:block;" doesn't help, and in either case the contenteditable element should not be duplicated.
  43. github.com/electron/electron/issues/8457
  44. github.com/rails/rails/issues/27570
  45. youtube.com/watch?v=nwvourv3nSQ
  46. github.com/basecamp/trix/pull/268
  47. github.com/rails/rails/pull/25826
  48. github.com/rails/rails/pull/25817
  49. weblog.rubyonrails.org/2016/6/30/Rails-5-0-final/

    Rails 5.0: Action Cable, API mode, and so much more

    After six months of polish, four betas, and two release candidates, Rails 5.0 is finally done! It’s taken hundreds of contributors and thousands of commits to get here, but what a destination: Rails 5.0 is without a doubt the best, most complete version of Rails yet. It’s incredible that this community is still going so strong after so long. Thanks to everyone who helped get us here.

  50. github.com/rails/rails/pull/25411
  51. github.com/rails/jbuilder/pull/341
  52. github.com/github/fetch/issues/340
  53. github.com/jeremy/rack-ratelimit/pull/3
  54. github.com/basecamp/local_time/pull/55
  55. twitter.com/javan/status/685182546498449408
  56. youtube.com/watch?v=n5MjAE-SN6c
  57. twitter.com/javan/status/647508073439866880
  58. github.com/github/gemoji/pull/63
  59. github.com/prawnpdf/ttfunk/pull/22
  60. github.com/rails/rails/pull/16793
  61. github.com/rails/rails/pull/12891
  62. github.com/github/gemoji/pull/37
  63. github.com/mikel/mail/pull/509