` directly under the body. Then, our html file that we served would have that `

` in that position too. ---

**Author:** ![tgelu](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/tgelu/32/1008_2.png) [@tgelu](https://discourse.elm-lang.org/u/tgelu)\ **Post date:** [July 6, 2020, 12:09pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/13 "2020-07-06T12:09:37Z")

Maybe not VDOM precisely, but Elm’s particular VDOM implementation. There are some other implementations out there that do not keep an internal model of the DOM as a base for the next update, but they use the real DOM state (which could have been altered by an external script) as the input to figure out the next changes. I remember someone proposed change in the VDOM algorithm to Evan at elm-europe, but don’t know how it landed. ---

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\ **Post date:** [July 6, 2020, 1:22pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/14 "2020-07-06T13:22:47Z")

> [@Chadtech](#): > > to modify the compiled javascript from the Elm compiler, so that `Browser.application` doesnt look for the `` tag, but instead looks for a `

` directly under the body Would it be a nice feature on a future version of the Elm compiler to be able to pass this as a parameter to the compiler? So you don’t have to do a post-compilation edit on the generated .js. ---

**Author:** ![Arkham](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/arkham/32/2624_2.png) [@Arkham](https://discourse.elm-lang.org/u/Arkham)\ **Post date:** [July 6, 2020, 3:16pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/15 "2020-07-06T15:16:23Z")

This is a problem for React as well: [https://bugs.chromium.org/p/chromium/issues/detail?id=872770](https://bugs.chromium.org/p/chromium/issues/detail?id=872770) ---

**Author:** ![dta](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/dta/32/1917_2.png) [@dta](https://discourse.elm-lang.org/u/dta)\ **Post date:** [July 6, 2020, 5:10pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/16 "2020-07-06T17:10:28Z")

You shouldn’t need to edit the compiled .js. You can pass a `node` parameter when you initialize the elm application, and it will place the app’s html there rather than directly in the body. ---

**Author:** ![antew](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/antew/32/2102_2.png) [@antew](https://discourse.elm-lang.org/u/antew)\ **Post date:** [July 6, 2020, 5:48pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/17 "2020-07-06T17:48:12Z")

With `Browser.element` you are correct, but if you are using a [Browser.application](https://package.elm-lang.org/packages/elm/browser/latest/Browser#application) Elm will take over the `` node. ---

**Author:** ![rupert](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/rupert/32/1775_2.png) [@rupert](https://discourse.elm-lang.org/u/rupert)\ **Post date:** [July 7, 2020, 12:03pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/18 "2020-07-07T12:03:19Z")

> [@dta](#): > > You shouldn’t need to edit the compiled .js. You can pass a `node` parameter when you initialize the elm application, and it will place the app’s html there rather than directly in the body. Perhaps that would be a better way to do it, rather than a compilation time flag - make `Browser.application` also allow the node to take over to be specified. ---

**Author:** ![Chadtech](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/chadtech/32/609_2.png) [@Chadtech](https://discourse.elm-lang.org/u/Chadtech)\ **Post date:** [July 8, 2020, 10:54pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/19 "2020-07-08T22:54:11Z")

> [@rupert](#): > > Would it be a nice feature on a future version of the Elm compiler to be able to pass this as a parameter to the compiler? So you don’t have to do a post-compilation edit on the generated .js. Im not sure. If there was an option to solve the problem, then I guess thats nice because it solves the problem. But its also a kind of obscure configuration detail. 1 configuration detail per problem that could possibly be solved by a configuration detail seems like a bad direction to go in tho, because such problem are possibly endless. One solution could be telling the `Elm.init()` function in JS what element to fill up. So you can pass in `documet.body` or anything else you want. Its worth noting that this is similar to how things were in 0.18, which didnt have the problem I originally mentioned. 0.19 changed, in that it doesnt allow Elm apps that do navigation to render in anything less than the ``, and I believe that choice was because that would permit the possibility of a small Elm widget being an `Browser.application` and therefore having full control over the navigation. It doesnt seem like a small widget should have that responsibility. Its likely to get into navigation conflicts with other things on the page. Just reverting that decision in 0.19 could be the simplest solution, but it would become a possible again for small Elm widgets to control navigation. And anyway, I kind of like Elm’s ambitious approach of taking over everything. Seems like the right direction, even if its difficult and uncharted territory for frontend technology. So again, I dont know how to solve it. ---

**Author:** ![eimfach](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/eimfach/32/3247_2.png) [@eimfach](https://discourse.elm-lang.org/u/eimfach)\ **Post date:** [July 11, 2020, 1:39pm UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/20 "2020-07-11T13:39:47Z")

I think this is a higher kinded problem of the DOM API … I think one solution could be DOM manipulation transactions and DOM manipulation locks. I think this needs to be addressed at the DOM specification level. ---

**Author:** ![supermario](https://yyz1.discourse-cdn.com/flex035/user_avatar/discourse.elm-lang.org/supermario/32/92_2.png) [@supermario](https://discourse.elm-lang.org/u/supermario)\ **Post date:** [July 19, 2020, 7:59am UTC](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994/21 "2020-07-19T07:59:55Z")

This has been raised before, this thread has lots of good discussion, workarounds and references: > [@Fullscreen Elm App in 0.19 (childNode issue) Reopened](https://discourse.elm-lang.org/t/fullscreen-elm-app-in-0-19-childnode-issue-reopened/3174): > > Continuing the discussion from [JavaScript Exception: Cannot read property childNodes of undefined, with extension Dark Reader](https://discourse.elm-lang.org/t/javascript-exception-cannot-read-property-childnodes-of-undefined-with-extension-dark-reader/2748/5): I am reopening this as I believe it is a big issue for real world Elm applications. At Humio are have big problems with browser extensions and third-party trackers and other scripts in our Elm application. We finally after several weeks of hard work were able to convert from 0.18 -\> 0.19. We use a fullscreen elm application to be able to control navigation etc. We dep… Also this: > [Next page](https://discourse.elm-lang.org/t/how-do-you-handle-runtime-exceptions-caused-by-extensions/5994.md?page=2)