Revision history [back]

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the ¿HomeScreen? then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the ¿HomeScreen? then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the ¿HomeScreen? then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the ¿HomeScreen? HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

I'll upload a screen cap when I have more karma...

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen.screen. A link to a test bookmark, copy to the Home screen and run in an empty browser: data:,breaksbrowsers.

The bug remains in the December '14 update.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in the December '14 update.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in the December '14 update.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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:

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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 `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 this post to a wiki page unintentionally, and can't see how to undo that, but at least now others may be able to add images.

If I use a string starting "data:" in the browser, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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 this post to a wiki page unintentionally, and can't see how to undo that, but at least now others may be able to add images.

If I use a string starting "data:" in the browser, browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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 this post to a wiki page unintentionally, and can't see how to undo that, but at least now others may be able to add images.

If I use a string starting "data:" in the browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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 this post to a wiki page unintentionally, and can't see how to undo that, but at least now others may be able to add images.

If I use a string starting "data:" in the browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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 this post to a wiki page unintentionally, and can't see how to undo that, but at least now others may be able to add images.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.

If I use a string starting "data:" in the browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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.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.

If I use a string starting "data:" in the browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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.

If I use a string starting "data:" in the browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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,<script language="javascript">alert("hello!");</script>
• data:text/html,<b>&lt;b&gt;</b> <i>&lt;i&gt;</i> <pre contenteditable="true" style="color:red;">red editable? </pre>

If I use a string starting "data:" in the browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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,<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>

If I use a string starting "data:" in the browser address/URL text input box, the corresponding browser screen renders as expected, so far as I can see. But if I then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly with no other open tabs before the bookmark is opened via the Home/bookmarks screen. 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 in testing, though.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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 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.

If I use a string For strings starting "data:" in the browser address/URL text input address box, the corresponding browser screen renders as expected, so far as I can see. But if I expected. To then save the address as a bookmark and put the bookmark on the HomeScreen, then running that same bookmark shortcut crashes the browser when it is called. tapped. The browser closes before the page renders.

Note: to recreate the bug, the browser must be closed, possibly closed with no other open tabs before the tabs. The bookmark is opened via the Home/bookmarks screen. A 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 in testing, though.it.

The bug remains in 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.

I cannot talk about the need for conversion wrt safety or anything else, except to note 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.