Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Crash on new tab using fetch #8233

Closed
mahalde opened this issue Feb 13, 2020 · 5 comments
Closed

Crash on new tab using fetch #8233

mahalde opened this issue Feb 13, 2020 · 5 comments
Labels
closed/wontfix feature/new-tab good first issue priority/P5 Not scheduled. Don't anticipate work on this any time soon.

Comments

@mahalde
Copy link

mahalde commented Feb 13, 2020

Description

The new tab (brave://newtab) crashes when using fetch in the browser console.

Steps to Reproduce

  1. Open a new tab (brave://newtab)
  2. Open the browser console
  3. type in fetch('https://brave.com')

Actual result:

The browser window crashes.

Expected result:

The window should continue to function normally.

Reproduces how often:

Every time.

Brave version (brave://version info)

Brave 1.3.115 Chromium: 80.0.3987.87 (Official Build) (64-bit)
Revision 449cb163497b70dbf98d389f54e38e85d4c59b43-refs/branch-heads/3987@{#801}
OS Windows 10 OS Version 1809 (Build 17763.973)

Version/Channel Information:

  • Can you reproduce this issue with the current release?
    Yes.
  • Can you reproduce this issue with the beta channel?
    Haven't tried.
  • Can you reproduce this issue with the dev channel?
    Haven't tried.
  • Can you reproduce this issue with the nightly channel?
    Haven't tried.

Other Additional Information:

  • Does the issue resolve itself when disabling Brave Shields?
    No.
  • Does the issue resolve itself when disabling Brave Rewards?
    No.
  • Is the issue reproducible on the latest version of Chrome?
    No.

Miscellaneous Information:

@rebron rebron added priority/P5 Not scheduled. Don't anticipate work on this any time soon. feature/new-tab labels Apr 17, 2020
@rebron
Copy link
Collaborator

rebron commented Apr 17, 2020

Reproduced on:

Brave 1.7.92 Chromium: 80.0.3987.163 (Official Build) (64-bit)
Revision e7fbe071abe9328cdce4ffedac9822435fbd3656-refs/branch-heads/3987@{#1037}
OS macOS Version 10.15.5 (Build 19F53f)

Screen Shot 2020-04-17 at 8 17 40 AM

@bsclifton
Copy link
Member

@cookster9
Copy link

I did some digging on this, but not sure if I’ll make any more progress. I’ll drop what I found here.

I saw that error code "185" is returned in the command line when running a local build of Brave. In the chromium code here, 185 is labeled as: WEBUI_BAD_SCHEME_ACCESS. That label is found in some unit testing code here with a useful comment: "Verifies that WebUI pages with WebUI bindings can't make network requests.” WebUI pages with WebUI bindings are basically any page with address chrome:// (or brave://).

So this crash will happen on any of those types of pages, like brave://settings. Not just on new tab. I confirmed if you run fetch(‘https://www.brave.com') from Brave settings you’ll also get a crash.

@bigfoxtail
Copy link

https://chromium.googlesource.com/chromium/src.git/+/master/docs/webui_explainer.md#security-considerations

WebUI pages cannot embed http/https resources or frames
WebUI pages cannot issue http/https fetches

This is chrome's security policy.
It seems to be possible to change the security policy for the WebUI bindings, but I don't know where to change it.
Or modify the web_ui_url_loader_factory.cc file, but that would make the browser insecure.
If you have found a way to do this, I hope you can explain to me the following
thanks😀

@bsclifton
Copy link
Member

Good find @bigfoxtail 😄 I didn't consider that was why it was happening

You are correct - WebUI does not have access to fetch external resources and that is 100% expected. The usual flow when external content is needed would be that JavaScript on the page will communicate with native handlers registered for the Web UI page. That native C++ code then has access to fetch whatever it needs

Given that this is a limitation of Web UI and we won't want to change it (due to security considerations), I'm going to close this issue as wontfix

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
closed/wontfix feature/new-tab good first issue priority/P5 Not scheduled. Don't anticipate work on this any time soon.
Projects
None yet
Development

No branches or pull requests

5 participants