The default bug view has changed. See this FAQ.

Null Tab Preview shown in SeaMonkey 1.1.1 with Modern theme

RESOLVED FIXED in mozilla1.8.1

Status

SeaMonkey
General
RESOLVED FIXED
10 years ago
10 years ago

People

(Reporter: Steve Snyder, Assigned: Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com])

Tracking

({fixed-seamonkey1.1.1})

1.8 Branch
mozilla1.8.1
x86
Windows 2000
fixed-seamonkey1.1.1
Bug Flags:
blocking-seamonkey1.1.1 +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

10 years ago
In the 18 Feb 2007 nightly of SeaMonkey v1.1.1 (ftp://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-mozilla1.8/seamonkey-1.1.1.en-US.win32.installer.exe), the Tab Preview of the current tab consists of an empty tooltip when the Modern theme is in use.

The Tab Previews show correctly with the default Classic theme(SVG thumbnail with non-current tab, tooltip colored text with current tab).  It is only when the Modern theme is in use that the the current tab displays a tootip with no text.  The empty tooltip displays as a small rectangular box hovering above the tab.  The rectangle has no text and contains no color.  Non-current tabs are shown in Modern with the correct SVG thumbnail.

Comment 1

10 years ago
linux too
Assignee: general → cst
Component: General → XP Apps: GUI Features
Flags: blocking-seamonkey1.1.1?
OS: Windows 2000 → All
Oops.  This is fallout from Bug 34517
Blocks: 345178
Component: XP Apps: GUI Features → General
OS: All → Windows 2000
(Reporter)

Comment 3

10 years ago
(In reply to comment #2)
> Oops.  This is fallout from Bug 34517

This is fallout from a bug fixed 7 years ago?
(In reply to comment #3)
> (In reply to comment #2)
> > Oops.  This is fallout from Bug 34517
> 
> This is fallout from a bug fixed 7 years ago?
> 

Yes.  Or maybe I meant bug 345178 ;).
Created attachment 255604 [details] [diff] [review]
patch (sort of...)

This helps somewhat.  Unfortunately it doesn't fix it 100% of the time.

Comment 6

10 years ago
Comment on attachment 255604 [details] [diff] [review]
patch (sort of...)

Well, it's a start...

Comment 7

10 years ago
Is this enough for 1.1.1?
If so, we should get it in fast and respin builds - we want to release really soon, if possible...

Updated

10 years ago
Flags: blocking-seamonkey1.1.1? → blocking-seamonkey1.1.1+

Comment 8

10 years ago
Comment on attachment 255604 [details] [diff] [review]
patch (sort of...)

I think we can go with this at least as a stopgap, it seems to resolve the issue for me even if you don't find it 100% effective.
Attachment #255604 - Flags: review+
Attachment #255604 - Flags: approval-seamonkey1.1.1+
(In reply to comment #8)
> (From update of attachment 255604 [details] [diff] [review])
> I think we can go with this at least as a stopgap, it seems to resolve the
> issue for me even if you don't find it 100% effective.
> 

Checked in on branch and trunk.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Keywords: fixed-seamonkey1.1.1
Resolution: --- → FIXED
Reopening.  On further examination, I can't believe the patch fixes anything.
Status: RESOLVED → REOPENED
Keywords: fixed-seamonkey1.1.1
Resolution: FIXED → ---
Created attachment 255895 [details] [diff] [review]
this seems to actually work

...makes me think this is gecko's fault.
Attachment #255604 - Attachment is obsolete: true
Attachment #255895 - Flags: superreview?(neil)
Attachment #255895 - Flags: review?(neil)

Comment 12

10 years ago
Comment on attachment 255895 [details] [diff] [review]
this seems to actually work

>+                       onpopuphiding="return this.parentNode.parentNode.parentNode.resetPreview(this);" orient="vertical">
Don't "return", the return value is ignored here.

>+      <!-- This should not be needed, but it seems that the tooltip sizing is
>+           happening too early when we want to stop showing the preview.  This
>+           clears the label's width early (i.e. when the previous preview
>+           disappears) so that when the next tooltip appears, it doesn't start
>+           with a bad size.  For now, I blame Gecko. -->
>+      <method name="resetPreview">
>+        <parameter name="aPopup"/>
>+        <body>
>+        <![CDATA[
>+          var label = aPopup.firstChild;
>+          label.removeAttribute("width");
>+          return true;
>+        ]]>
>+        </body>
>+      </method>
IMHO you should remove the tabpreview attribute too.
Either way, you don't need to remove it/them in doPreview any more.
r+sr=me with these fixed.
Attachment #255895 - Flags: superreview?(neil)
Attachment #255895 - Flags: superreview+
Attachment #255895 - Flags: review?(neil)
Attachment #255895 - Flags: review+
Attachment #255895 - Flags: approval-seamonkey1.1.1?
Backed out the old fix and checked in the new one on trunk, with Neil's comments addressed.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → FIXED

Comment 14

10 years ago
Comment on attachment 255895 [details] [diff] [review]
this seems to actually work

Let's get 1.1.1 rolling... a=me
Attachment #255895 - Flags: approval-seamonkey1.1.1? → approval-seamonkey1.1.1+
Checked in on branch.
Keywords: fixed-seamonkey1.1.1
You need to log in before you can comment on or make changes to this bug.