Open Bug 761727 (TBAppTabs) Opened 12 years ago Updated 2 years ago

Implement app / pinned tabs for Thunderbird

Categories

(Thunderbird :: Toolbars and Tabs, enhancement)

x86
All
enhancement

Tracking

(Not tracked)

People

(Reporter: mconley, Unassigned)

References

()

Details

(Whiteboard: [patchlove])

Attachments

(1 file, 5 obsolete files)

Patches for the App Tabs feature will go here.
Attached patch WIP patch (obsolete) — Splinter Review
WIP Patch June 18th 2012
(In reply to Nguyen Ngoc Trung from comment #1)
> Created attachment 634140 [details] [diff] [review]
> WIP patch
> 
> WIP Patch June 18th 2012

Trung:

Can you please update your patch here with whatever you currently have?

Thanks,

-Mike
Attached patch WIP Patch (obsolete) — Splinter Review
I was trying to implement the Persist function before uploading the patch but unsuccessful :( I still got segmentation fault, it is segmentation fault 11.
Trung:

Can you give me a minimal set of steps to reproduce the segfault?

-Mike
I'm not sure, but I sometimes get this by:
1. Open Thunderbird, load and pin some tabs.
2. Quit the app or wait for Thunderbird's session manager to save the session.
3. Open the Thunderbird and wait for a while.
Then I get segmentation fault 11.
(In reply to Nguyen Ngoc Trung from comment #5)
> I'm not sure, but I sometimes get this by:
> 1. Open Thunderbird, load and pin some tabs.
> 2. Quit the app or wait for Thunderbird's session manager to save the
> session.
> 3. Open the Thunderbird and wait for a while.
> Then I get segmentation fault 11.

Ok. I'll see if I can reproduce it. At the same time, can you try running TB through a debugger, and try to get me a backtrace?
Attachment #634140 - Attachment is obsolete: true
Trung:

Just a note about your comment about the crash - what you're hitting is an Assertion Failure. There are assertions all over the Mozilla codebase to ensure that certain things meet our expectations. In debug builds, when we fail an assertion, we intentionally crash (fail loud, fail proud).

Getting a backtrace for this crash would help us determine how you got there. When you crash a debug build, it should give you 300 seconds to attach a debugger to the process. From there you can get a backtrace.

Come find me in IRC today if you're still experiencing this, and I'll show you how to do that.

-Mike
Attached patch WIP (obsolete) — Splinter Review
Attachment #639443 - Attachment is obsolete: true
Thanks for the WIP patch Trung, keep 'em coming!
Attached patch WIP (obsolete) — Splinter Review
Attachment #653087 - Attachment is obsolete: true
Assignee: ip_trungnguyen → trunga0
Whiteboard: [patchlove]
Blocks: 605652
Assignee: trunga0 → josiah
Whiteboard: [patchlove]
Attached patch WIPSplinter Review
Not even close to done, but now it is semi-functional.
Attachment #653195 - Attachment is obsolete: true
Going to keep this assigned just for memory purposes, but I may not get to this for a little several weeks.
Whiteboard: [feel_free_to_submit_patch_even_if_assigned]
I'm extremely busy, so I'm un-assigning myself, at least for the time being.
Assignee: josiah → nobody
Blocks: tabsmeta
Severity: normal → enhancement
Whiteboard: [feel_free_to_submit_patch_even_if_assigned] → [patchlove]

When can we expect this feature?
It's over 8 year old now and I'm missing it every day?

I noticed an increased activitiy on old bug-entries, maybe this bug can be considered too?

Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.