Selecting multiple messages in a folder with a lot of messages causes CPU to spike, application to become unresponsive

[Guilherme Salgado]

After upgrading to Thunderbird 15, whenever I select a dozen or so messages in a folder with a lot of messages, the CPU usage spikes and TB becomes unresponsive for a few seconds, after which it comes back to life and CPU usage goes back to normal. I can reproduce it reliably.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: thunderbird 15.0+build1-0ubuntu0.12.04.1
ProcVersionSignature: Ubuntu 3.2.0-30.48-generic 3.2.27
Uname: Linux 3.2.0-30-generic x86_64
AddonCompatCheckDisabled: False
AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
ApportVersion: 2.0.1-0ubuntu12
Architecture: amd64
ArecordDevices:
 **** List of CAPTURE Hardware Devices ****
 card 0: PCH [HDA Intel PCH], device 0: CONEXANT Analog [CONEXANT Analog]
   Subdevices: 1/1
   Subdevice #0: subdevice #0
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: salgado 3312 F.... pulseaudio
BuildID: 20120827103657
Card0.Amixer.info:
 Card hw:0 'PCH'/'HDA Intel PCH at 0xf1620000 irq 52'
   Mixer name : 'Intel CougarPoint HDMI'
   Components : 'HDA:14f1506e,17aa21d2,00100002 HDA:80862805,80860101,00100000'
   Controls : 27
   Simple ctrls : 9
Card29.Amixer.info:
 Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw unknown'
   Mixer name : 'ThinkPad EC (unknown)'
   Components : ''
   Controls : 1
   Simple ctrls : 1
Card29.Amixer.values:
 Simple mixer control 'Console',0
   Capabilities: pswitch pswitch-joined penum
   Playback channels: Mono
   Mono: Playback [on]
Channel: Unavailable
Date: Mon Sep 10 14:29:32 2012
ForcedLayersAccel: False
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MostRecentCrashID: bp-81e41b5a-42e5-4b9e-9f52-1cf892120827
Profiles: Profile0 (Default) - LastVersion=15.0/20120827103657 (In use)
RelatedPackageVersions:
 google-talkplugin 3.5.1.0-1
 icedtea-6-plugin 1.2-2ubuntu1.2
 rhythmbox-mozilla 2.96-0ubuntu4.1
 totem-mozilla 3.0.1-0ubuntu21
RunningIncompatibleAddons: False
SourcePackage: thunderbird
UpgradeStatus: Upgraded to precise on 2012-01-17 (237 days ago)
dmi.bios.date: 04/09/2012
dmi.bios.vendor: LENOVO
dmi.bios.version: 8CET53WW (1.33 )
dmi.board.asset.tag: Not Available
dmi.board.name: 4170CTO
dmi.board.vendor: LENOVO
dmi.board.version: Not Available
dmi.chassis.asset.tag: No Asset Information
dmi.chassis.type: 10
dmi.chassis.vendor: LENOVO
dmi.chassis.version: Not Available
dmi.modalias: dmi:bvnLENOVO:bvr8CET53WW(1.33):bd04/09/2012:svnLENOVO:pn4170CTO:pvrThinkPadT420s:rvnLENOVO:rn4170CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
dmi.product.name: 4170CTO
dmi.product.version: ThinkPad T420s
dmi.sys.vendor: LENOVO

[Justdave-mozilla (justdave-mozilla)]

Created attachment 652043
Process sample via Activity Manager while hung

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Thunderbird/17.0a1
BuildID: 20120814030529

For the last few weeks, typing a string in the filter box at the top of a folder message list pane, and the selecting multiple items in the results and attempting to delete them results in Daily immediately consuming multiple GB of RAM and hanging until it's force-quit.

[Ludovic-mozilla (ludovic-mozilla)]

Confirming,; just having multiple selection kills the ponies.

[Ludovic-mozilla (ludovic-mozilla)]

Dave is mail.operate_on_msgs_in_collapsed_threads set to true ?

[Vseerror (vseerror)]

perhaps same as bug 753502

[Justdave-mozilla (justdave-mozilla)]

(In reply to Ludovic Hirlimann [:Usul] from comment #2)
> Dave is mail.operate_on_msgs_in_collapsed_threads set to true ?

It is set to the default value, which is true, yes, I also have threading disabled in most of my folders (including the ones I've run into this in) in case it matters)

[Ludovic-mozilla (ludovic-mozilla)]

Dave do these emails have attachments ?

[Justdave-mozilla (justdave-mozilla)]

They are "page changed" notifications from Confluence, which are multipart/html with embedded pics and css, so yes.

I've also discovered that simply opening one of these can cause the RAM usage explosion.

[Vseerror (vseerror)]

(In reply to Dave Miller [:justdave] from comment #6)
> They are "page changed" notifications from Confluence, which are
> multipart/html with embedded pics and css, so yes.
>
> I've also discovered that simply opening one of these can cause the RAM
> usage explosion.

how much memory per message?
regression?

[Justdave-mozilla (justdave-mozilla)]

(In reply to Wayne Mery (:wsmwk) from comment #7)
> (In reply to Dave Miller [:justdave] from comment #6)
> > They are "page changed" notifications from Confluence, which are
> > multipart/html with embedded pics and css, so yes.
> >
> > I've also discovered that simply opening one of these can cause the RAM
> > usage explosion.
>
> how much memory per message?

It usually immediately jumps to around 3.5 GB to 4.0 GB physical in use, and then starts swapping. It continually grabs more memory once it starts, until I force quit.

> regression?

Yes. I could read these without getting this problem a few weeks ago.

[Vseerror (vseerror)]

the oldest regression report I find is Bug 759092 - though I'm not convinced it's the same issue.

justdave, could you hunt the regression range?
Bug 759092 cites failure using 2012-05-25 build

[Mike Conley (mconley)]

Profiling this shows us spending an inordinate amount of time in jsmimeemitter.js, in the writeBody function:

http://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/components/jsmimeemitter.js#455

Profile posted here:

http://people.mozilla.com/~bgirard/cleopatra/?report=ace22cfa16f76a49a787d5d705c5474c68e72633

Cc'ing asuth and protz because this is Gloda stuff.

[Joshua Cranmer (jcranmer)]

This is the function in question:

455 writeBody: function mime_emitter_writeBody(aBuf, aSize, aOutAmountWritten) {
456 if (this._writeBody &&
457 (!this._saneBodySize ||
458 this._curPart.body.length < MAX_SANE_BODY_PART_SIZE))
459 this._curPart.body += aBuf;
460 },

If memory is leaking like crazy, then probably this accumulation is where it's going. Likely that means that either the sane body part size isn't being checked, or there are a lot of not-quite-max-size parts getting added.

It sounds like there's a specific message (or set of messages) that's causing this issue; can this be posted?

[Jonathan Protzenko (jonathan-protzenko)]

Shot in the dark: it may be a message with an insane amount of parts, or many such messages.

[Ludovic-mozilla (ludovic-mozilla)]

Created attachment 654764
testcase

(In reply to Jonathan Protzenko [:protz] from comment #12)
> Shot in the dark: it may be a message with an insane amount of parts, or
> many such messages.

NO not more than 3. Message coming up. Can't save it from tb so you'll get the untouched message eg without the mbox headers.

[Joshua Cranmer (jcranmer)]

(In reply to Ludovic Hirlimann [:Usul] from comment #13)
> Created attachment 654764
> testcase
>
> (In reply to Jonathan Protzenko [:protz] from comment #12)
> > Shot in the dark: it may be a message with an insane amount of parts, or
> > many such messages.
>
> NO not more than 3. Message coming up. Can't save it from tb so you'll get
> the untouched message eg without the mbox headers.

52 parts. It looks like it's basically of the form:

multipart/mixed
  multipart/alternative
    text/msg
    multipart/related
      text/html
      ... Several cid: images ...
  application/pdf

Each image averages about 1/3KB of de-base64'd size. Oh, and the images are all Content-Disposition: attachment too, fwiw.

[Bugmail-asutherland (bugmail-asutherland)]

I see MultiMessageSummary in the profile; not a lot, but a little. I assume this is a case where MultiMessageSummary is either overwhelmed by what it is streaming to provide a useful summary and/or it is making things worse by re-computing things. I think the summaries have some logic to wait for quiescence based on a timer; if the system has become overwhelmed, it is conceivable that things appear to quiesce to pour some gasoline on the fire. It's been long enough that I don't recall the exact event sequence for the summaries so I don't know how possible that is.

I doubt gloda's indexer is involved because all types of deletion should appear to gloda as either a fast-pathed move or an actual deletion. (gloda does show up in the profile a teeny bit, but that could just be background-ness.)

[Bugmail-asutherland (bugmail-asutherland)]

It's worth noting that because of the way XPConnect works, even if the emitter has stopped concatenating the strings because saturation has been reached, all those calls still happen and those tiny strings will still generate tons of garbage. And I think in the case of HTML, those calls may not be lined-based, but tag-based, in which case the garbage generation could be a ridiculous multiplier since HTML e-mails can include a ridiculous number of tags. I suspect Joshua may know more about that (and his MIME parser may not have this pathological problem).

[Ludovic-mozilla (ludovic-mozilla)]

FWIT before I came back from vacation , I could read these emails without any issues.

[Irving (irving)]

I have this reproduced, so I'll dig in with debugger and tracing. If someone else can find a regression window by testing old Daily builds that would be great.

[Irving (irving)]

Oh now this is interesting (and annoying...) The Aug 1 nightly build (https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012-08-01-04-20-04-comm-aurora/) beachballs and consumes a big chunk of CPU when I select several messages in a folder including the test message, but it *doesn't* consume gigabytes of memory - whereas trunk as of last Thursday eats both CPU and memory.

That means we get to bisect two problems - the CPU load before Aug 1 and the memory bloat after.

[Bugmail-asutherland (bugmail-asutherland)]

Could be massive garbage generation in both cases, but the GC is just running more frequently (and/or running full cycle collecting GC's more frequently), so we don't actually bloat as much. The profiler should label GC's, so if that's the case now, it should be pretty obvious pretty fast. (Based on the previous profile, I would expect the I/O should still be very obvious.)

It's probably also worth checking with gdb that the I/O hasn't stopped being buffered or something like that. Specifically, check the length of the strings to make sure they are not 1 character long...

[Irving (irving)]

Parts of the problem seem to have come and gone. The basic regression window is:

OK: https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/05/2012-05-14-05-31-54-comm-aurora/

FAILED: https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/05/2012-05-15-03-05-24-comm-central/

so the problem seems to have been introduced May 14. The May 15 build has both CPU load and memory bloat; the May 30 build has CPU load but not memory bloat, and the memory reappears some time after Aug 1.

[Irving (irving)]

Bah, I messed up and mixed Aurora and Nightly builds in my bisection. The problem is earlier than May 14 in nightlies. Bisect bisect bisect.

[Irving (irving)]

OK, this time for sure ;->

Good nightly: https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/05/2012-05-03-03-16-32-comm-central/thunderbird-15.0a1.en-US.mac.txt

Bad nightly: https://ftp.mozilla.org/pub/mozilla.org/thunderbird/nightly/2012/05/2012-05-04-03-36-16-comm-central/thunderbird-15.0a1.en-US.mac.txt

Looking at the changes, there's nothing obvious in comm-central; unfortunately I can't get a successful build of either the good or bad revision to test/bisect further.

I haven't read all the mozilla-central changes during that time frame yet.

[Mozilla-ex (mozilla-ex)]

I've always suspected the compartment changes in moz-central that landed around that time.

[Irving (irving)]

David, good catch - compartment-per-global for XPConnect landed that day. If I recall correctly, mconley's profiler runs showed a bunch of time spent in the cross-compartment JS call path.

[Irving (irving)]

OK, so it's a combination of things:

1) the message summary generator uses Gloda's mime structure builder to parse content out of messages, in order to get the first couple of lines to summarize: https://mxr.mozilla.org/comm-central/source/mail/base/content/selectionsummaries.js#585

2) libmime splits messages into text lines and calls the mime "emitter" with the message content line-by-line

3) Gloda's builder reassembles that content into a single string for plaintext and html parts: https://mxr.mozilla.org/comm-central/source/mailnews/db/gloda/components/jsmimeemitter.js#455

Unfortunately the string building at step 3 happens in a way that interacts terribly with compartment-per-global; for some reason the string assignment is happening across a compartment boundary and among other things this forces the JS string to be flattened, so there is insane amounts of memory allocation going on inside a tight loop that doesn't have any GC pauses - so we both burn huge amounts of CPU copying strings, and we blow out the heap by keeping all the copies.

The quick fix is to make selectionsummaries.js pass the "saneBodySize:true" flag to MsgHdrToMimeMessage() - this stops the gloda builder from reassembling the entire string.

This still leaves behind a cruel trap for anyone else who uses the Gloda mime engine, we need to fix the underlying problem as well.

[R-luke-h (r-luke-h)]

(In reply to Irving Reid (:irving) from comment #26)
Any number of things can cause a string to be flattened so, in general, code should not rely on strings not being flattened. However, part of comment 26 sounded worrying so I'd like to ask for a clarification: are all these huge strings live (i.e., they are in some array or other object structure that is reachable) or should they be garbage that, for some reason, isn't being collected? If it is the latter, this may be a GC scheduling bug, independent but exacerbated by bug 650353.

[Bugmail-asutherland (bugmail-asutherland)]

Ah, the flattening... good investigatory find! As a simple horribleness-reducer, we could change to just putting the strings in a list and calling join at the end.

[Joshua Cranmer (jcranmer)]

(In reply to Irving Reid (:irving) from comment #26)
> Unfortunately the string building at step 3 happens in a way that interacts
> terribly with compartment-per-global; for some reason the string assignment
> is happening across a compartment boundary and among other things this
> forces the JS string to be flattened, so there is insane amounts of memory
> allocation going on inside a tight loop that doesn't have any GC pauses - so
> we both burn huge amounts of CPU copying strings, and we blow out the heap
> by keeping all the copies.

This may be caused by how the gloda mimemsg.js architecture works. mimemsg.js is a JS module that is imported by Cu.import, while the code that appends body parts is a JS component called back by libmime. The this._curPart is synthesized from a function in mimemsg.js, so it generates a cross-compartment wrapper, so most of our manipulation from the JS emitter is going through cross-compartment calls (and xpconnect!).

[Irving (irving)]

Luke: I agree that we don't want to rely on flattener and GC behaviour; in fact, while the CPU burn on this bug has been constant since CPG landed the memory bloat has come and gone a few times so it could very well be related to GC scheduling.

Step one of my preferred approach would be to figure out a way to have all the objects in the mime message assembler be inside the same compartment so that we don't need to proxy any of the calls; then we can look at fixing the inefficient way we assemble the big string.

[Irving (irving)]

Created attachment 656201
Don't accumulate the entire message body in MIME emitter when creating message summaries

Passing this option prevents the gloda MIME emitter from building extra-large strings containing MIME part contents, which reduces the impact of string copying and CPG enough to get by.

asuth: Should we also pass partsOnDemand:true to avoid further downloading, or does aAllowDownload=false already avoid problems with getting MIME parts from the server?

callek: mxr didn't find any other non-test calls to MsgHdrToMimeMessage(), but someone should check SM to make sure it doesn't have a similar problem if it uses the gloda MIME emitter.

[Justin Wood (Callek) (bugspam-callek)]

Comment on attachment 656201
Don't accumulate the entire message body in MIME emitter when creating message summaries

redirecting to Neil for SeaMonkey "OMG will this break us, or do we need to port" Q, since I know very little about this part of our code.

[Mike Conley (mconley)]

FWIW, I just tried this patch on a collection of messages that the TB generally chokes on when multi-selecting.

There is a significant improvement to performance - it's still a little sticky, but it certainly doesn't send TB into a tailspin like it did before.

Great detective work, Irving!

[Neil-httl (neil-httl)]

Comment on attachment 656201
Don't accumulate the entire message body in MIME emitter when creating message summaries

I'm looking at newsblogOverlay.js because I think that's the only shared code (we don't have the code that summarises message selections). Is there no way to get just the headers, or better still, just the content-base header from the message, and no body at all?

[Jonathan Protzenko (jonathan-protzenko)]

> asuth: Should we also pass partsOnDemand:true to avoid further downloading, or
does aAllowDownload=false already avoid problems with getting MIME parts from
the server?

aAllowDownload=false means: "if the message is not available locally (offline sync or message cache), don't download it over the internet, and use the very little information we have from the headers in the .msf file"

partsOnDemand=true means: "if fetching the message remotely (because it isn't fully available locally), and the server is IMAP, and the server supports BODYSTRUCTURE, use it to not download parts too big, but still create a complete Mime structure for the message"

I think aAllowDownload=false takes precedence.

[Bugmail-asutherland (bugmail-asutherland)]

Comment on attachment 656201
Don't accumulate the entire message body in MIME emitter when creating message summaries

As protz says, the default (which is now being explicitly set) for allow download (=false) should avoid any network traffic anyways. I think setting saneBodySize is definitely a good stop-gap.

I don't think there's any way to avoid the JS component being in its own compartment without changes to the way the emitter is instantiated, which leaves us moving all of the representation gunk from mimemsg.js to jsmimeemitter.js and leaving the calls that trigger the streaming in mimemsg.js.

Specifically, gloda.manifest lists the category manage entry: "category mime-emitter @mozilla.org/messenger/mimeemitter;1?type=application/x-js-mime-message @mozilla.org/gloda/jsmimeemitter;1" which is how it gets instantiated We could have the streaming process take a pre-constructed XPConnect-looking object and have all the MIME helper stuff operate by using the subscript loader inside the same context as whatever wants to consume it. We would probably want to use a RequireJS-type idiom (with 'use strict' to avoid global pollution). This would likely want to entail a change to similarly most of the gloda modules in a similar fashion.

Having said that, I think just having the representation classes loaded in the emitter compartment should be sufficient to stop the worst of the pain. That and maybe encouraging the C++ shim that defines the emitter layer to perform a little more internal batching so the XPConnect wrapping is not quite so over-the-top.

[Ludovic-mozilla (ludovic-mozilla)]

*** Bug 753502 has been marked as a duplicate of this bug. ***

[Matt Dorn (matt-dorn-gmail)]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.82 Safari/537.1

Steps to reproduce:

Just noticed this after upgrading to 15.0. I have ~500 messages in my Inbox (Gmail account). I selected 50 of them (holding down Shift and clicking) to bulk delete them.

Actual results:

The CPU spikes and the application becomes unresponsive for several seconds.

Expected results:

The application shouldn't care how many messages you select, and should respond without any trouble.

[Jsabash (jsabash)]

Matt, this may be dup of bug 782899
Could you take a look there.
One way to prove it is to (temporarily) turn off Gloda indexing and see if the problem goes away.

[Jsabash (jsabash)]

I guess it's not as simple as disabling Gloda to prove the dup.
Message summaries, and some extensions can cuase this too.

[Matt Dorn (matt-dorn-gmail)]

Yes, much of the behavior described in bug 782899 (and especially in bug 753502, which has been tagged as a duplicate of 782899) is similar to my experience, though I never saw much of a memory spike -- only a CPU spike, and the application becoming unresponsive for up to 20 seconds or so.

That said, I did a "Repair Folder" on my Inbox, and that seems to temporarily relieve the problem, allow me to quickly select multiple messages, etc., but the effect is short-lived -- once I start re-ordering, etc., in the folder I'm back to the same problem.

Again, this problem is new with my upgrade to 15.0 today -- never had it before then.

[Ludovic-mozilla (ludovic-mozilla)]

I'm going to mark this as a duplicate, we have two bugs one for memory one for cpu. Just forgot the one aboutt cpu. duping to the most visible one, irving is anyhow working on both issues.

*** This bug has been marked as a duplicate of bug 782899 ***

[Ludovic-mozilla (ludovic-mozilla)]

*** Bug 787121 has been marked as a duplicate of this bug. ***

[Vseerror (vseerror)]

several potentially matching topics taggged https://getsatisfaction.com/mozilla_messaging/tags/tb15perf

TB15.0.1 coming?? :)

[Irving (irving)]

Checked in:

https://hg.mozilla.org/comm-central/rev/4ac6d862637f

but see Bug 784286 to track further work necessary...

[Acelists (acelists)]

Is this specific to TB17 or can it be in TB15 too?
Here are some bugs like this: bug 787348, bug 787321.

[Matt Dorn (matt-dorn-gmail)]

@aceman: yes, I believe the bug is in TB15 official release. Here's my experience after upgrading: bug 787121

@:wsmwk -- I agree that a TB 15.0.1 release containing this fix is needed -- I actually had to roll back to TB14, and am happily productive again.

[Acelists (acelists)]

There are potential reports that may be a dupe of this. Will this patch be backported to some branches?

[Standard8 (mbanner)]

Comment on attachment 656201
Don't accumulate the entire message body in MIME emitter when creating message summaries

[Triage Comment]
Taking this onto beta so we can get some testing.

[Standard8 (mbanner)]

Checked in:

https://hg.mozilla.org/releases/comm-aurora/rev/f0b6d2317205
https://hg.mozilla.org/releases/comm-beta/rev/0564977e1c9d

[Acelists (acelists)]

Is this going into 15.0.1 please? So we can see if the tons of similar bugs are dupes.

[Acelists (acelists)]

*** Bug 789019 has been marked as a duplicate of this bug. ***

[Standard8 (mbanner)]

Comment on attachment 656201
Don't accumulate the entire message body in MIME emitter when creating message summaries

[Triage Comment]
The general feedback so far has been that this and bug 784286 are fixing issues, so taking onto the release branch.

[Standard8 (mbanner)]

Checked in:

http://hg.mozilla.org/releases/comm-release/rev/4c39c77cfe36

[Vseerror (vseerror)]

*** Bug 789722 has been marked as a duplicate of this bug. ***

[Guilherme Salgado (salgado)]

Originally linked it to https://bugzilla.mozilla.org/show_bug.cgi?id=787121 but that's in turn marked as a dupe of https://bugzilla.mozilla.org/show_bug.cgi?id=782899. The former describes the issue I'm seeing but I'm linking to the other as upstream says they're dupes

[Acelists (acelists)]

Irving, we get reports in other bugs about this, that in TB15.0.1 the memory (freeze) problem is solved but now not all of the selected messages are summarized in the message pane. Is that a known side effect of the patch?

[Acelists (acelists)]

*** Bug 788541 has been marked as a duplicate of this bug. ***

[Acelists (acelists)]

*** Bug 787321 has been marked as a duplicate of this bug. ***

[Acelists (acelists)]

*** Bug 787348 has been marked as a duplicate of this bug. ***

[Bugmail-asutherland (bugmail-asutherland)]

(In reply to :aceman from comment #51)
> Irving, we get reports in other bugs about this, that in TB15.0.1 the memory
> (freeze) problem is solved but now not all of the selected messages are
> summarized in the message pane. Is that a known side effect of the patch?

There should be no side-effect like that. But be aware that the summarization logic caps MAX_THREADS to 100 and MAX_MESSAGES to 100, so it could just be people are being more observant and noticing this limitation.

[Acelists (acelists)]

Are they informed about that? Does the preview pane contain some "further messages were hidden" footnote?

[Ludovic-mozilla (ludovic-mozilla)]

(In reply to :aceman from comment #56)
> Are they informed about that? Does the preview pane contain some "further
> messages were hidden" footnote?

yes at the bottom of the summary view

[Jbg-w (jbg-w)]

In my case, I don't see any notice that not everything was summarized. For 9 messages, total size is 14MB.

[Vseerror (vseerror)]

https://getsatisfaction.com/mozilla_messaging/topics/tb15_0_is_horrid_slow marked solved

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Acelists (acelists)]

*** Bug 790755 has been marked as a duplicate of this bug. ***

[Rolf Leggewie (r0lf)]

this is marked as fixed upstream, for TB15. Do you still experience this for TB17?

[Guilherme Salgado (salgado)]

No, it seems to be fixed in TB17