webview setting baseURLForDataURL crashes Electron

[burningTyger]

Preflight Checklist

• I have read the Contributing Guidelines for this project.
• I agree to follow the Code of Conduct that this project adheres to.
• I have searched the issue tracker for an issue that matches the one I want to file, without success.

Issue Details

• Electron Version:
• 7.0.0
• Operating System:
• Arch Linux
• Last Known Working Electron version:
• 6.0.10

Expected Behavior

Opening a webview with a preset source as in:

<webview src="https://github.com"></webview>
<script>
webview.loadURL(
   `data:text/html;charset=utf-8;base64,
    PGgxPkhBTExPPC9oMT4=
  `, { baseURLForDataURL: `file://home/` })
// the base64 string is just <h1>HALLO</h1>
</script>

loads the github URL and then reloads the webview with HALLO.

Actual Behavior

Electron crashes

To Reproduce

See this repo:
https://github.com/burningTyger/webview-bug

Screenshots

Additional Information

[vladimiry]

It's not the webview only specific. It crashed even if you call window.webContents.loadURL on a regular window in the case if baseURLForDataURL is specified.

A quite severe issue. @sofianguy hope it gets moved Unsorted Issues => Fixed for Next Release soon :)

[evanrolfe]

This bug is occuring for me too in v7.0.0.

However you said Last Known Working Electron version: 6.0.10, are you sure its working in that version? Because it seems like for me in version 6.* using baseURLForDataURL does not crash the app, however it does mean that the webview renders nothing at all.

[vladimiry]

are you sure its working in that version

Works for me in 6.0.10 (no crhash and rendering is ok), but for regular window, didn't try the webview.

Electron 8-beta1 is also affected.

[burningTyger]

no, works as expected in 6.0. Maybe you can open another issue with a repo?

[evanrolfe]

Thanks for the quick replies @vladimiry and @burningTyger. I've cloned your webview-bug repo and although you code does indeed run in 6.0.10, if you change baseURLForDataURL to an HTTP URL then it fails (the program doesn't crash but the webview doesn't render at all), even in version 6.0. For example this is what I have changed the code to:

  let webview = document.querySelector('webview');
    webview.addEventListener('dom-ready', () => {
      webview.loadURL(
          `data:text/html;charset=utf-8;base64,
          PGgxPkhBTExPPC9oMT4=
          `, { baseURLForDataURL: `https://github.com/` })
          //This will fix the issue:
          // `)
    })

Electron version 5.0.0-beta.2 is the last version in which this works. Though perhaps this is a seperate bug, I can write up a new issue for this if the maintainers would like me to?

[vladimiry]

@sofianguy v8 also crashes, can you add a respective label?

[Xernisfy]

I encountered a similar problem with BrowserWindow.
Up to Electron version 6.1.4, this worked for me (Windows10 64bit):

const { app, BrowserWindow } = require('electron');
app.on('ready', () => {
  new BrowserWindow().loadURL(
    'data:text/html;charset=UTF-8,' + encodeURIComponent('<script src="test.js"></script>'),
    { baseURLForDataURL: 'C:/Users/xxx/Documents/' }
  );
});

Where test.js only contains console.log('hi') and it was printed to the console correctly.
Since Electron v7.0.0 the window only shows up briefly and then crashes immediately.

Without the baseURLForDataURL it doesn't crash.
Of course, there's no 'hi' is in the console, however there is no error that test.js couldn't be found either.
I expected something like Failed to load resource: net::ERR_FILE_NOT_FOUND like in most cases.
I even tried this with the file protocol prefix file:// as well, but to no avail.

Thanks in advance for any help

[vladimiry]

Just tried the recently released v8-beta3. The problem is still there, the app crushes.

Received signal 4 ILL_ILLOPN 55c9168eaedd
#0 0x55c916eacd89 (/dev/temp/electron-base-url-issue/node_modules/electron/dist/electron+0x34c4d88)
  r8: 00002effab5c9b00  r9: 00007ffd87698f90 r10: 0000000000000085 r11: 0000000000000004
 r12: 00002effab9efef8 r13: 00002effab75d6c0 r14: 00007ffd87699820 r15: 00002effaa3db500
  di: 00007ffd87699280  si: 00002effa96a4cc0  bp: 00007ffd876994e0  bx: 00002effa97cdc60
  dx: 0000000000000002  ax: 0000000000000000  cx: fffffffd51b75717  sp: 00007ffd87699410
  ip: 000055c9168eaedd efl: 0000000000010246 cgf: 002b000000000033 erf: 0000000000000000
 trp: 0000000000000006 msk: 0000000000000000 cr2: 0000000000000000
[end of stack trace]
Calling _exit(1). Core file will not be generated.

[marvin-martian]

A little work around. If you register your own file protocol (@see https://electronjs.org/docs/api/protocol) and use that as the baseURLForDataURL the crashing stops and you can access your files.

{baseURLForDataURL: 'atom:/'}

Of course this doesn't solve the crashing problem. :-/
It effects both the BrowserWindow and BrowserView

[vladimiry]

Can confirm the custom protocol workaround is functional, just tested it on v8-beta3, thanks @marvin-martian.

[burningTyger]

It stops the crashes for me but in my webviews I now can't access further assets for which I need the baseURLForDataURL. Maybe I'm doing it wrong?

[vladimiry]

@burningTyger I simply exposed the specific directory in the app path via file protocol https://github.com/vladimiry/ElectronMail/blob/6135622cf73d11e783204074734016453fdcc64c/src/electron-main/protocol.ts#L32-L60 I didn't try using other/non-file protocol types as a workaround, might also work.

[burningTyger]

@sofianguy I also tested this issue with platfom/mac and electron 8 beta and it also fails. Maybe the tags can be added as well?

[cyphercodes]

+1 confirmed, any ideas what's causing this?

[ghost]

@burningTyger Here's the code I tried and it works by using the file protocol hack.

const { app, BrowserWindow, protocol } = require('electron')
const path = require('path')
app.on('ready', () => {
  protocol.registerFileProtocol('tron', (request, callback) => {
    const url = request.url.substr(6)
    const file = { path: path.normalize(`${__dirname}/${url}`) }
    callback(file)
  })
  new BrowserWindow().loadURL(
    'data:text/html;charset=UTF-8,' + encodeURIComponent('<link rel="stylesheet" href="./src/css/main.css">'),
    { baseURLForDataURL: 'tron:/' }
  )
})

Just copy paste it in your index.js file and obviously you would need your own css file and path. Put some background-color: #000 to test

[burningTyger]

@catalin-luntraru I appreciate the help but this might work for BrowserWindow not so for webview. It stops the crashing but doesn't find the resource with the new protocol. Apparently the protocols don't work with webviews.

[vladimiry]

protocols don't work with webviews.

It does work with webviews, here https://github.com/vladimiry-playground/electron-quick-start-baseURLForDataURL

[burningTyger]

@vladimiry super hero! I tried right after you posted and it failed again. Today I was going to try for real and I noticed I had copied the __dirname without much thought and after I ls'ed the files I noticed it had my build dir. Then it finally dawned on me that I had the script's path in it. So, sorry for my incompetence and thank you for posting a complete example.

[vladimiry]

Thanks go to @marvin-martian who revealed the workaround. The issue was a blocker for me but the workaround allowed upgrading the electron version.

[Xernisfy]

Can confirm the workaround with electron v8.0.0
Modified version of my previous attempt:

const { app, BrowserWindow, protocol } = require('electron');
const path = require('path');
app.on('ready', () => {
  protocol.registerFileProtocol('el', (request, callback) => {
    callback({ path: path.normalize(decodeURIComponent(request.url.substr(3))) });
  });
  new BrowserWindow().loadURL(
    'data:text/html;charset=UTF-8,' + encodeURIComponent('<script src="test.js"></script>'),
    { baseURLForDataURL: 'el://C:/Users/xxx/Documents/' }
  );
});

It now works fine.
Thank you guys!

[burningTyger]

One thing I notice though is that the devtools fail to load maps: DevTools failed to parse SourceMap: file2:///....

[FI-GGG]

可以用电子
版v8.0.0确认我先前尝试的修改版本：

const { app，BrowserWindow，protocol } =  require（' electron '）;
const  path  =  require（' path '）;
应用程式。上（'准备就绪'，（）=> {
   协议。registerFileProtocol（' EL '，（请求，回调）=> {
     回调（{路径： 路径。正规化（decodeURIComponent（请求。URL。SUBSTR（3）））}）; 
  }）; 新的BrowserWindow（）。loadURL（
     ' data：text / html; charset = UTF-8，' + encodeURIComponent（' <script src =“ test.js”> </ script> '），
    {baseURLForDataURL ：' el：// C：/ Users / xxx / Documents / ' } 
  ）; 
}）;
      

现在可以正常工作了。
感谢大伙们！

electron 8 rendering process will not report an error using require ()?
My program keeps reporting that the require method is not defined.

[ThatAnton]

This bug is also not unique to linux despite the tags on this issue. I'm experiencing it on mac with electron 7.1.3. I also tried going back to v6 which as mentioned by @evanrolfe, does not cause a crash but instead causes an ERR_FAILED loading error which results in a blank webview.

[Swyrough]

Also experiencing this on Windows 10 with 8.2.2

[Xernisfy]

electron 8 rendering process will not report an error using require ()?
My program keeps reporting that the require method is not defined.

This probably occurs because nodeIntegration was not enabled in my example.

Try to use this object as parameter for the BrowserWindow constructor:

{webPreferences:{nodeIntegration:true}}

[all789-pixel]

Also experiencing this on Ubuntu with 9.0.0

[hmt]

In its latest iteration (9.0.x) this bug also requires me to serve other files from subsequent pages with the new prefix. This bug seems only to appear on Windows. On macOS it works without explicitly setting the prefix (e.g. file2://)

Just in case someone encouters the not allowed to load local resource message, this will fix your problem.

[gschier]

Just ran into this issue. As a workaround, I'm injecting the <base href="..."> tag into the <head> of the HTML, which effectively does the same thing, albeit with a much less reliable method (string replacement).

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/base

[futurelucas4502]

This is still broken in electron 10 please say this will be fixed at some point as it would be really useful to have it working correctly

[kirkouimet]

$50 via any payment method to whoever fixes this

[JordanDaigle]

Still seem to be an issue on electron v11.1.1, but as mentionned above, making a custom file protocol fix the problem :

 const customProtocol = 'file2';
   
 protocol.registerFileProtocol(customProtocol, (request, callback) => {
   const url = request.url.substr(customProtocol.length + 2);
   const file = { path: path.normalize(`${__dirname}/${url}`) }
   callback(file)
 });
 
 let win = new BrowserWindow({
   webPreferences: {
     nodeIntegration: true,
     contextIsolation: true
   }
 })
   
 win.loadURL(`data:text/html;charset=UTF-8,${encodeURIComponent(indexHTML)}`, {
   baseURLForDataURL: `${customProtocol}://${app.getAppPath().replace("\\", "/")}/`
 });

[antiremy]

A quick (and unsafe) fix I found on v10.1.1 is to run app.commandLine.appendSwitch('disable-site-isolation-trials'); before doing anything with app.on('ready').

This lets you set the baseURLForDataURL to something with the https protocol without any crash

[nojsja]

Registering a custom protocol and require a module with a relative path will be failed stil.
Temporary solution:

try {
       result = _require(_path);
 } catch(error) {
       result =
          _require(path.join(path.dirname(document.baseURI), _path).replace('file:', ''));
  }

[nornagon]

Duplicate of #28407

[vladimiry]

@nornagon is not #28407 duplicate of this one (as was opened before)?

[marvin-martian]

@nornagon And this issue points to the more general issue in that baseURLfoDataURL is broken. Having work arounds is not fixing the broken issue.

[nornagon]

I've marked this issue as a duplicate of #28407 because they share the same underlying cause, and because that issue has more information about that cause.

[Juice10]

@nornagon I set up a Electron Fiddler of the portion of this problem that doesn't use a custom protocol and thus doesn't overlap with #28407 but still crashes: https://gist.github.com/7c979306285b7b8a4588261663ce5a8b

Maybe we could re-open this issue for that use case?

[nornagon]

@Juice10 thanks for the repro! I've narrowed it down a little bit and opened #28765 to track that crash.