# [bug] Browser startup crash for URL "data:mime,content", launched from homescreen shortcut

asked 2014-12-22 21:49:30 +0200

This post is a wiki. Anyone with karma >75 is welcome to improve it.

For strings starting "data:" in the browser address box, the corresponding browser screen renders as expected. To then save the address as a bookmark and put the bookmark on the HomeScreen, running that same bookmark shortcut crashes the browser when tapped. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed with no other open tabs. The bookmark is opened via the Home/bookmarks screen. Here is a link to a test bookmark, copy to the Home screen and run in an empty browser: data:,breaksbrowsers. I could not get my Jolla to bookmark that link or follow it.

The bug remained after the December '14 update.

Below is a (zoomed in) screen capture of the browser when the bookmark is loaded in a new tab or from the bookmarks menu view:

There's also some character conversion going on when data: addresses like data:text/html,<html... are opened and as well when they get bookmarked. The greater than, less than and quote marks get changed to %Hex codes. Please cancel this conversion for data: addresses.

It seems, to some degree, that the "making safe" part perhaps ought not to be visible to the user in character conversions.

data:text/html,%22%3Chtml%3E%3Cbody%3E%3Cpre contenteditable=true%3E%3E%22%3E %3C%3C/pre%3E%3C/body%3E%22

I changed the tag address-bar to bookmarks to reflect the notion that the issue seems to primarily stem from there. Bookmarks without titles do not always update the text shown in the absence of a label, when the URL changes, so I perceive, rightly or wrongly, that bookmark storage and editing are buggier, especially when unsafe characters like quote marks and less than and greater than are used. Tag Issues may relate to how markup is treated on the bookmarks menu if the address begins data: instead of something more familiar like http[s]. If the data value after the mime type contains pre, b or i, some formatting takes place in the bookmarks list. This possibly is among the things interfering with success in the browser with the data: address prefix. As shown below, pre creates a newline, b makes label bold and i goes italic. Tags also disappear. In the bookmarks list this oughtn't to happen, since the list is not the browser window (post parse of markup).

I did not report this as a new bug since the data: issues raised here might be symptoms of the same few missing or extraneous lines of code.

The text in the bookmarks shown in the image differs from the input text:

• data:text/html,This is a text.
• data:text/html,<script language="javascript">alert("hello!");</script>
• data:text/html,<script>alert("The scissor test");</script>
• data:text/html,<b>&lt;b&gt;</b> <i>&lt;i&gt;</i> <pre contenteditable="true" style="color:red;">red editable? </pre>

I added the backtick characters that make the list items appear in boxes above. If the script bookmarks cannot be reproduced then that is because the data: content was changed and saved but the display bookmark did not change to reflect the new text (name fields were always empty). Sometimes the browser, on save or on load, seems to corrupt the bookmark record by converting from a character to its 'safe' version.

The script links hang mid-load, and the alert dialogs only display with reloads. Once again, sorry for lumping these issues into one question's detail: it is just hard to kniw where one stops and other begin.

edit retag close delete

The data:initcrashissue hobbles browser effectiveness, such using the browser and bookmarks to create formatted and plaintext notes via contenteditable HTML attributes. Another blocker to this is the current browser's inability to save webpages to the local disk: https://together.jolla.com/question/73458/how-can-i-save-webpages-to-disk-from-the-browser/

As soon as data: bookmarks from the launcher no longer crash the browser, users become able to extend and tailor their device interface according to their wishes. This simplifies things significantly, imo.

( 2014-12-26 01:56:48 +0200 )edit

This is no longer a valid crash bug since the last release, at least, as far as my cursory testing showed me. Zoomed-in rendered text is very ugly though, it does not sharpen as before or resolve clearly, and the test url, data:,crashmebaby/ghg downloaded a resulting text file with an odd and untidy filename ("file:///home/nemo/Downloads/Fhn2zS7K").

20150309011648.jpg

( 2015-03-09 01:27:38 +0200 )edit

data:text/html,%3Cb%3Ehhjghg%3C/b%3E`

The link opened into a second tab from its bookmark in the bookmarks GUI just caused the browser to hang. I had to reboot to get the browser to be responsive to any touch input.

The browser was the only thing running.

Carefully-crafted, carelessly-copied, make-safedly-mangled... data URIs, bookmarks or links, still need some something.

( 2015-04-15 08:11:27 +0200 )edit