Closed Bug 370832 Opened 18 years ago Closed 18 years ago

Null Tab Preview shown in SeaMonkey 1.1.1 with Modern theme

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
1.8 Branch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8.1

People

(Reporter: swsnyder, Assigned: csthomas)

References

Details

(Keywords: fixed-seamonkey1.1.1)

Attachments

(1 file, 1 obsolete file)

this seems to actually work
2.73 KB, patch
neil
: review+
neil
: superreview+
kairo
: approval-seamonkey1.1.1+
Details | Diff | Splinter Review
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.
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
(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 ;).
Attached patch patch (sort of...) (obsolete) — — Splinter Review
This helps somewhat. Unfortunately it doesn't fix it 100% of the time.
Comment on attachment 255604 [details] [diff] [review] patch (sort of...) Well, it's a start...
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...
Flags: blocking-seamonkey1.1.1? → blocking-seamonkey1.1.1+
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
Closed: 18 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 → ---
...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 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
Closed: 18 years ago → 18 years ago
Resolution: --- → FIXED
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+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: