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

AUDIO tag stops SAFE Browser from rendering #196

Closed
btbonval opened this issue Oct 2, 2017 · 10 comments
Closed

AUDIO tag stops SAFE Browser from rendering #196

btbonval opened this issue Oct 2, 2017 · 10 comments

Comments

@btbonval
Copy link

btbonval commented Oct 2, 2017

Operation System: Linux 64-bit
Beaker Version: ??
SAFE Browser Version: 0.6.0 (alpha-2)
Notes: I'm using mocknet. Compiled and run with NODE_ENV=dev.

Problem

If I include an AUDIO tag (from the HTML5 standard), the SAFE Browser will load that page correctly, then it will not render any new pages or reload any previously loaded pages. Existing pages continue to render.

I have evidence that the page does execute but does not render. This is based on the dev tools, which shows the full set of page contents as being populated. Additionally, an AUDIO tag set to autoplay will play even when the HTML is not rendered.

I see this problem with both file:// and safe:// protocols.

Steps to reproduce

  1. Grab any mp3 file. I'm using a small one that is only a few seconds long. Name the file file.mp3.
  2. Save below text as an HTML file alongside file.mp3.
  3. Open the HTML file in the SAFE Browser using file://. It will load. (Optionally: upload the two files using web hosting manager and open it using safe://, the result will not change)
  4. Create a new tab. Reload previously open tabs. Open the HTML file over again. None render.

HTML file:

<!DOCTYPE html>
<HTML LANG="en">
  <HEAD>
    <META CHARSET="utf-8"/>
    <META NAME="viewport" CONTENT="width=device-width, initial-scale=1.0">
    <TITLE>Music Player</TITLE>
  </HEAD>
  <BODY>
    <P><A HREF="index.html">Back to splash.</A></P>
    <AUDIO src="file.mp3" controls="true"></AUDIO>

  </BODY>
</HTML>

More info

Once the rendering stops, Window > Developer Tools > Reload Shell Window causes the whole window to go blank outside the menu (all tabs are lost).

Closing and restarting the SAFE Browser will allow the browser to render again... an AUDIO tag shows up.

Related issues

I searched both https://github.com/beakerbrowser/beaker/issues and https://github.com/electron/electron/issues for issues related to Audio tags, but could not find any case in which the rendered display was relevant.

@hitman401
Copy link

Thanks for bringing it up to our notice. However, this seems to be a chromium related issue which ripples in electron. Here is the link to the issue . We will check into the issue certainly and figure out what best we can do. Thanks again!

@btbonval
Copy link
Author

btbonval commented Oct 3, 2017

@krishnaIndia Reading through that ticket, it would appear the issue is specifically that AUDIO or VIDEO tags don't work.

In the case reported here, the AUDIO tag does work: the mp3 audio plays just fine.

After loading a page with AUDIO successfully, however, the SAFE Browser will not render any pages (even those with no AUDIO tag).

@hitman401
Copy link

@btbonval, I get you now. A similar issue was also reported previously in one of the testnets. We will try to reproduce this at our end and resolve.

@joshuef
Copy link
Collaborator

joshuef commented Oct 3, 2017

@btbonval what flavour of linux are you running?

I was not able to reproduce this on OSX or Ubuntu 16.04

@btbonval
Copy link
Author

btbonval commented Oct 4, 2017

@joshuef

I'm testing under Linux Mint 18.1 which appears to be based on Ubuntu 16.04.

So after loading an HTML page with an AUDIO tag, you could open new tabs and they rendered using SAFE Browser built from alpha-2 tag on git?

@btbonval
Copy link
Author

btbonval commented Oct 5, 2017

I wanted to highlight more of my workflow and version numbers, since @joshuef and I are running similar operating systems.

For the original error report above, I was using the alpha-2 tag with commit 5cc7965. However, someone changed the beaker-plugin-safe-app-0.3.0.tgz file without updating the file version or file name, so alpha-2 doesn't work anymore:

error https://s3.eu-west-2.amazonaws.com/beaker-plugin-safe-app/beaker-plugin-safe-app-0.3.0.tgz: Fetch succeeded for undefined. However, extracting "https://s3.eu-west-2.amazonaws.com/beaker-plugin-safe-app/beaker-plugin-safe-app-0.3.0.tgz" resulted in hash "93ff8377180dc84c046b8598a15b9cd61190437a", which did not match the requested hash "496a9b46ffc32e050a5a636629dc4bd23d656de5".

Side note: please update version numbers when changing a file or append the hash onto the file name. It really helps keep things consistent between source repos and static file hosting. Appending the hash to file names is common for files hosted on CDN to avoid similar out-of-sync problems between e.g. HTML and CSS, JS and HTML, or two JS files, which might be updated independently.

Just like with web_hosting_manager, the solution was to ditch the tag and switch to master.

So now I'm using safe_browser master with commit bf21e5e with a fresh compiled version of the browser.

I'm using the following versions:

  • nvm 0.33.4
  • node 7.10.1
  • yarn 1.0.2

My build process:

export NODE_ENV=dev
yarn upgrade
yarn burnthemall
yarn run package
tar -czf safe_browser-0.6.0-bf21e5eb-dev.tgz dist/

There's an intermediary step here because I sandbox dev from testing as a matter of personal practice. I move the tgz to a new system.

tar -xzf safe_browser-0.6.0-bf21e5eb-dev.tgz
export NODE_ENV=dev
./dist/linux-unpacked/safe-browser

To keep the replication steps as simple as possible:

  1. I loaded the browser
  2. Did not login
  3. Clicked File > Open File
  4. Chose the html file with an AUDIO tag
  5. Did not play the audio nor have the audio set to autoplay (it opened just fine and looked correct)
  6. Opened a new tab: tab was blank and did not render the usual tab screen.

@joshuef
Copy link
Collaborator

joshuef commented Oct 6, 2017

Thanks for the detailed updates!

One note on your build process, you want to have a yarn build step before you package, as this will update bundles js.


I have evidence that the page does execute but does not render.

If this is the case, it could well be that you're hitting a browser tab/webview issue. There's been some problems with electron webviews not rendering properly. Perhaps you can try increasing z-index of the webview via devtools of the browser (or tweaking some other css)?


Sorry to say, @btbonval we don't support mint at the moment. We don't have a system to test against so I can't dig deeper. (As noted, everything worked as expected on Ubuntu 16.)

I'll leave this open for now incase you're able to debug the browser tabs via devtools 👍

Thanks @btbonval

@btbonval
Copy link
Author

btbonval commented Oct 6, 2017

Thanks for the feedback, @joshuef .

I thought yarn burnthemall included yarn build. I'll double check that.

The good news is that the problem isn't reproducible ;) That means, generally, an app with AUDIO should work for most people, and it can be tested even when this error is present, it just requires restarting the browser sometimes.

The dev tools show up. I can even inspect the HTML, but nothing on the page highlights. I'll try changing the z-index as an experiment.

However, if I use Reload Shell Window after an AUDIO tag is used, all actual the tabs disappear and the window is only left with its title and the menu. It amplifies the problem. Hard to imagine that's related to z-index, but I don't really know what reloading the shell window does.

I'll post any experiment results here.

@joshuef
Copy link
Collaborator

joshuef commented Oct 9, 2017

Reload Shell Window is actually reloading the whole electron app/user interface so yeh, that's going to be a hard refresh on everything.

Even your devtools would be destroyed as the BrowserWindow electron element which it is attached to is destroyed.

I'll post any experiment results here.

👍

@bochaco bochaco closed this as completed Dec 12, 2017
@bochaco
Copy link
Member

bochaco commented Dec 12, 2017

I'm closing this now as we are not supporting Mint for the moment. Please feel free to re-open it if this issue is seen still in the supported platforms though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants