Skip to content
New issue

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

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

Already on GitHub? # 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

# for free to join this conversation on GitHub. Already have an account? # 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