365642 - View Selection Source on a few selected cells within a huge table displays the entire table source [and consumes large amounts of memory and loops with high cpu]

Status: NEW

(Toolkit :: View Source, defect, P3)

Description

[Martijn Wargers (dead)]

See url.
Go to the bottom of the page where there isn't any text anymore in table cells.
Select a few lines of those table cells and the do a 'View Selection Source' in the context menu.

Actual result:
Firefox consumes > 500MB of memory (I had a case of >1.5GB, but I'm afraid of finishing the view selection source process, because with that memory usage, it brings my system to a crawl).

Expected result:
Firefox consuming < 500MB of memory, preferably, it should just use a few extra MB's.

It seems that Firefox1.5.0.9 isn't that memory hungry when doing the steps to reproduce, it 'just' uses something like 200-300MB.

Comment 1

[Martijn Wargers (dead)]

Attachment: Page in question, zipped

The page in question, attached to the bug, in case the url disappears.

Comment 2

[Martijn Wargers (dead)]

Attachment: Another page in question, zipped

Another page, where I got this issue. This time it's just a large amount of text in the page and the doing "View Selection Source" on some part of it.

Comment 3

[Wayne Mery (:wsmwk)]

(In reply to comment #0)
>...
> Actual result:
> It seems that Firefox1.5.0.9 isn't that memory hungry when doing the steps to
> reproduce, it 'just' uses something like 200-300MB.

1.5.0.9 compared to __?  

This essentially loops/hangs for me.

I selected the first couple lines, pick view selection and after several minutes I get "unresponsive script and I can't break out after selecting "stop script".
VM size is at 1.5meg and cpu 95%

maybe one of these?  http://tinyurl.com/y88jb5

Comment 4

[Peter Berry]

http://www.theyworkforyou.com/lords/?id=2006-10-17b.651.0&s=speaker%3A12913#g721.0

Selecting text from before this div until a little way into it, then viewing selection source, causes very high memory and CPU usage.

In addition, after a while (something like 20 seconds, I haven't measured it) a dialogue box pops up saying there is a misbehaving script and would I like to kill it. Clicking on "Stop script" has no effect (beyond closing the window, and even that takes a long time) and further boxes appear if I wait.

Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1

Also on the latest nightly build, will reply with its UA in a moment.

Comment 5

[Peter Berry]

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9a2pre) Gecko/20070128 Minefield/3.0a2pre

Comment 6

[bloopletech]

This bug (or a related one) affects ordinary pages as well, although to a lesser extent.

On the web application I am developing, if you view selection source on the whole page and then try to scroll down more than 1 page, then FF hangs for 10-15 seconds (I mean hangs all windows, no UI response etc.)

Just confirming that this does happen to a lot of page.

Comment 7

[Wayne Mery (:wsmwk)]

3.1 might be better, but still high impact on the huge testcase URL http://www.bkn.go.id/honorerhapus.htm
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1b2) Gecko/20081125 Firefox/3.1b2

Comment 8

[Martijn Wargers (dead)]

Testcase2 of bug 416052 ( https://bugzilla.mozilla.org/attachment.cgi?id=301807 ) also seems to exhibit this problem.

Comment 9

[Wayne Mery (:wsmwk)]

bz, is there a core bug this view source bug should depend on?

Comment 10

[Boris Zbarsky [:bzbarsky]]

I have no idea.  What's the actual JS running here?  Is it just being totally stupid in some way, or is it doing things that should be reasonable?

Comment 11

[Boris Zbarsky [:bzbarsky]]

That said, if someone can give me spefic steps to reproduce (e.g. on that page from comment 0, should I just be selecting some of the garbage text below he table?) I can try to at least profile...

Comment 12

[Boris Zbarsky [:bzbarsky]]

Here's a question.  Is the memory usage much different from the memory usage if you view the source of that frame?

Comment 13

[Wayne Mery (:wsmwk)]

bz, using v3.6 memory usage is about double that of a straight out, simply view source.

using attachment 250167 [details]
1. scroll to bottom of page
2. click scrollbar to go back(up) ~8 screens
3. select from there down to bottom
4. view selection source

however, high cpu is short lived, and memory not terrible - nothing debilitating to UI. memory varies 100-200mb.  Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2b1pre) Gecko/20090928 Namoroka/3.6b1pre

Martijn, is it better/worse with a newer version?

Comment 14

[Boris Zbarsky [:bzbarsky]]

Memory usage more than normal view source + size of actual page (since view selection source sticks all that stuff into a data: URI) is not quite expected, but not likely to be an obvious core bug; more likely to be a bug in the way view selection source builds up its huge string.  If cpu is not a problem, there's no point profiling.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 16

[Gregory Pappas [:gregp]]

Attachment: Test case from comment 1, unzipped

Comment 17

[Gregory Pappas [:gregp]]

Still a bit slow. https://share.firefox.dev/3TKkwoT

STR for the profile above:

1. Navigate to attachment 9325003 [details]
2. Scroll to the bottom of the table
3. Select the last few table cells which contain no visible text
4. Right click on the selection, click "View Selection Source"

The resulting data URI is about 4.2MB. There might be a more relevant bug to dupe this over to, but I can't find anything at the moment.

Comment 18

[Jonathan Kew [:jfkthame]]

Bug 1800596 is at least somewhat related, given that part of the issue here is the time it takes to create the massive textrun for the data URI we're trying to display in the location bar. There have been some improvements recently (see the dependent bugs there), but shaping multiple mega-characters of text can still be quite expensive. Especially if the system UI font includes OpenType features like ligatures and kerning, which it does at least on macOS.

Another issue here is that View Selection Source doesn't seem to be able to deal with a selection within a table; the resulting View Source window contains the entire table, not just the selected cells. And that's why it's so huge and performs so poorly, even though just a few empty cells were selected.

I'm updating the title and component here to focus on the latter issue, as that's what seems to be unique to this example, while other bugs like 1800596 are about the more general issue with huge data URIs.

Comment 19

[Jonathan Kew [:jfkthame]]

The issue here seems to occur if the selection in the table spans multiple rows, but not if it spans just some cells within a single row.

Comment 20

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:Honza, could you have a look please?

For more information, please visit BugBot documentation.

Comment 21

[Jan Honza Odvarko [:Honza] (always need-info? me)]

I can reproduce the issue with the current Firefox Nightly 122 using STRs from comment #17
(note that selectable cells are just underneath of the end of the big table)

The source page takes about ~6s to load and the data URI is about 4.2MB for me too.

Honza