Historically, cm_modes was used to lazily load CodeMirror MIME modes.
However, since we are no longer using CodeMirror MIME modes as
remote modules, we have switched to using ES imports to load them
instead. To that end, we made the `DefaultCodeMirrorMimeMode` extension
obsolete, as it became a noop for loading.
Moreover, cm_modes was loaded via the module.json infrastructure
present in the shell.json file. As such, in release mode these
files would properly load, but in a standalone (e.g. unit test)
environment, the missing links would cause these modes not to load.
To remedy the situation, we perform multiple fixes:
1. Remove the module.json extensions, since we are using ES imports
instead.
2. Remove DefaultCodeMirrorMimeMode.js (it is obsolete)
3. Move cm_modes.js into text_editor (this was the only module
that actually was loading the full version of CodeMirror)
4. Remove the infrastructure in CodeMirrorTextEditor.js to retrieve
the Mime modes (these were effectfully noops).
I have personally verified these Mime modes are still correctly
loading by opening a personal workspace with various Python/CC files
and confirmed that the syntax highlighting in the sources panel
is as expected.
R=aerotwist@chromium.org
Bug: 1127902
Change-Id: Ia3502713be247dc373e80fc3daa65ca7d9ecc1fe
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2577560
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Since issues is now TypeScript-authored and is the only module
that was relying on Marked, we are no longer bound by marked
being in a direct subdirectory of front_end. Therefore, we
can treat it as lit-html and directly import from
third_party/marked instead.
To make sure that we don't bundle Marked in issues itself,
we have to update the Rollup logic to exclude it for now.
We will clean that up in a future Cl, where we are changing
the heuristic for "bundliness".
R=szuend@chromium.org,jacktfranklin@chromium.org
Bug: 1011811
Change-Id: Ieb40470a9efcd072ff5b360b7bd487f15df2a689
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2529157
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
Reviewed-by: Simon Zünd <szuend@chromium.org>
This reverts commit 8f012723b7.
The cause of the i18n not working on debug configuration was that
some files were missing from the grd lists.
- Added i18nImpl, i18n-bundle.js with a similar process to the rest
of the modules.
To make it easy to review:
the first patchset contains the reland with no modifications the >2 patchset
contains the fixes, so if you diff Patchset 1 vs > 1 you should see the fixes
described above.
Change-Id: Iee3767b6afeb1a039be952f787886f94c0752f56
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2376945
Commit-Queue: Vidal Diazleal <vidorteg@microsoft.com>
Reviewed-by: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Peter Marshall <petermarshall@chromium.org>
front_end/Runtime.js was doing multiple things: it was instantiating
side-effecty descriptors and initializing applications, as well as
storing all state for the modules/extensions, etc...
To support proper ES Modules, we need to separate these. root/Runtime.js
contains simple classes that store the data and can be retrieved, as well
as some helper functions that will load the respective data.
The RuntimeInstantiator.js code includes the start functions used in the
entrypoints themselves. They will use an instance of the Runtime to
properly load the application.
Along the way, I also fixed various TypeScript errors, mostly around
incorrect or missing type definitions.
R=aerotwist@chromium.org,jacktfranklin@chromium.org
Bug: 1011811
Change-Id: If3ddea9267813691b3faeb6ea4b0cf64edbde1f4
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/2107523
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Jack Franklin <jacktfranklin@chromium.org>
This also makes cm_modes/ non-remote and uses proper dynamic imports to
load the code (rather than an `eval`). This increases the binary size by
104 KB from 11756K to 11860K which is an increase of 0.8%.
The stylus cm_mode has been removed. This mode was the largest mode
(30KB), seems unmaintained [1] and this syntax is likely rarely used (if
at all). It is unclear how often the other modes are installed and used.
Additionally, I discovered a promise race in the plugin installation. In
the full application this is not noticeable, as by default all code
mirror modes are lazily loaded (verified they still work with Markdown,
Java file and the regular js/cc files). However, in the test it was not
properly awaiting the plugin loading.
Perform the async-await plumbing to make sure the promise is resolved
before the test continues execution.
roll CodeMirror
[1]: https://github.com/codemirror/CodeMirror/commits/master/mode/stylus
Bug:1006759,1011466
Change-Id: If4d81d01318e08a63faaffee8b0cc9ab5954d4c6
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1928924
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
cm_web_modes/ was used both in a worker and in the normal browser
context. However, both formatter_worker/ and text_editor/ included the
relevant files in their scripts array.
The fix is to make cm_web_modes a proper module and import either the
browser (_cm.js) variant or the worker (_headless.js) variant.
Bug: 1006759
Change-Id: I85c6f67102d8ffd94e073850b1ac7adcb289b1b2
Reviewed-on: https://chromium-review.googlesource.com/c/devtools/devtools-frontend/+/1934218
Reviewed-by: Paul Lewis <aerotwist@chromium.org>
Commit-Queue: Tim van der Lippe <tvanderlippe@chromium.org>
The terminal experiment was initially proposed in 2016 [1]. Since then,
no maintenance work was performed on promoting the experiment to a
stable feature.
Closer inspection of the feature shows that it does not work. After
enabling the experiment, issueing the command "Show Terminal" results in
an internal error in xterm.
If we want to reconsider this experiment, we should re-evaluate the
approach and come up with a proper design for the feature. For now, I
would propose on removing the dead code.
[1]: https://codereview.chromium.org/2372303003
Bug: 1006759,1011466
Change-Id: Ib433b44924d9ccb1f5665afba9affcccd04c2bd8
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1855923
Commit-Queue: Yang Guo <yangguo@chromium.org>
Auto-Submit: Tim van der Lippe <tvanderlippe@chromium.org>
Reviewed-by: Yang Guo <yangguo@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#705165}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: da5f866faa7e93ca75874023017fb6ff8aa5b75b
Tim van der Lippe
