Side note, I'd love a first class "hasClass" type Javelin function.

Not having this method is an explicit design decision, and I don't ever plan to provide this method. See here for some discussion, under "Sigils":

https://secure.phabricator.com/book/javelin/article/sigils_metadata/

Briefly:

• At Facebook, an innocent designer rounded the corners of a dialog and broke the dialog behavior. This was the custom privacy dialog, and the dialog no longer saved changes when submitted, so you'd set your post to "just me" and save, but the setting would stay "public".
• This was because the Javascript relied on some CSS class like dialog-no-rounded-corners to dictate logical behavior (the class name wasn't quite this ridiculous, but not far off).
• Not having hasClass() means that it is much harder for change which makes design adjustments to also change behavior, because we know that (except in rare, extreme cases) no Javascript depends on whether a class is present or not, since we don't have a method for even testing this in the library. So we can be more confident that making CSS and class adjustments is almost always safe, and almost always only affects display behavior.

In this case, imagine we move remarkup-fullscreen-mode from body to a container div. That seems totally innocent and no one would think twice about writing or reviewing it, and it would survive testing since neither the author nor reviewer would be likely to test fullscreen + send on enter, but would break this behavior silently.

This kind of code (using CSS class names for both display behavior and logical behavior) is inherently fragile. Both engineers and designers reasonably assume they can make minor changes to CSS, class names, and the DOM without breaking how the application works, and that these kinds of changes will generally only affect the UI.

A generalization of this issue is the idea of "using the DOM as a datastore". Broadly, it's almost always bad for the answer to any logical question to every rely on the state of the DOM.

Instead, your application code should store the state itself (in classes and objects), and should publish that state to the DOM as necessary, but should not read state from the DOM which could be stored in the application and read from the application instead.

These functions are generally bad:

function is_thing_enabled() {
  return has_class(document.body, 'thing');
}

function set_thing_enabled(enable) {
  if (enable) {
    add_class(document.body, 'thing');
  } else {
    remove_class(document.body, 'thing');
  }
}

These functions are generally a better (primarily: more robust) way to build this:

function is_thing_enabled() {
  return this.isEnabled;
}

function set_thing_enabled(enable) {
  // Set the state record in the application, not the DOM.
  this.isEnabled = enable;

  // Now publish the state to the DOM, which is just a view of the application.
  JX.DOM.alterClass(document.body, this.isEnabled);
}

We don't have hasClass() because 99% of the time it's used to write the bad version of is_thing_enabled().

All that said, we don't currently have a great place to store this state, since none of the other remarkup behaviors depend on global state. We probably need some kind of new state-storing thing to deal with this, plus T8200, plus T11171, plus "Sheets" (e.g., when you click a task on a workboard, load a "new browser tab" into the same page using Javascript) if we're going to pursue those. I don't really have a clear picture of what that should look like yet, and the answer probably mostly depends on what "Sheets" are going to look like.

An alternative -- and perhaps better -- approach would be to move this behavior into the remarkup area itself. That is:

• When creating a remarkup input in PHP, have a method like setSendOnEnter(true).
• That passes some flag to the phabricator-remarkup-assist behavior.
• When that behavior sees a "return" key, checks the state of the control and submits the form if the "return" is valid (for example: not in fullscreen mode).

This could potentially let us fix stuff like the :3<return> bug in a more graceful way, too -- that's a minor case, but it's a situation where the behavior of the "return" key depends on a different, complicated piece of remarkup state. If we add more stuff like that in the future, it would probably be better for the control to handle send-on-enter than for Conpherence to ask the control a bunch of questions about whether send-on-enter is OK or not.

A simpler change would be to implement half of this: let PHP specify setSendOnEnter(true), have that just disable the "fullscreen" option with no other effects, and leave the rest of the code in place until we can deal with this more properly.

oh wait hold on

I expect that didSyntheticSubmit should be sufficient on its own, without calling form.submit(). What issue are you seeing without form.submit()?