Closed
Bug 325296
Opened 18 years ago
Closed 17 years ago
JavaScript opacity for text in <div> element is broken, no problem on branch
Categories
(Core :: Layout, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: hanzov69, Assigned: roc)
References
()
Details
(Keywords: regression)
Attachments
(3 files, 3 obsolete files)
1.40 KB,
text/html
|
Details | |
2.65 KB,
patch
|
Details | Diff | Splinter Review | |
1.86 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; de-de) AppleWebKit/412.6 (KHTML, like Gecko) Safari/412.2 Build Identifier: Camino Nightly Build for January 30th, 2006 Version 2006013008 (1.0+) Javascript attempts to create a "fade-in" effect ( see http://freezerpants.com/test/moo.fx.js under fx.Opacity ) however, in the the nightly, the text just doesn't appear. The invisible text can be highlighted (but not seen), verified by copying/pasting invisible text. Reproducible: Always Steps to Reproduce: 1.Load http://freezerpants.com/test/test.html 2.Watch as text quickly flashes/disappears 3.Enjoy invisible text :) Expected Results: text should toggle fade in / fade out
Comment 1•18 years ago
|
||
Confirming with a trunk nightly. This was NOT broken in 1.0b2, so something broke between the branch and now. (On a side note, Safari doesn't handle this as nicely as Camino 1.0b2 does.) I suspect this is Core, but it may be another one of those really weird Core bugs that only affects Camino. cl
Comment 2•18 years ago
|
||
I'm sorry, this is trunk only, correct? (Thus 1.0b2 has nothing to do with it.) This works fine for me using Version 2006012804 (1.0b2+). Marking as trunk.
Version: unspecified → Trunk
Comment 3•18 years ago
|
||
This is the same issue as in bug 324940. Basically, 'opacity' is broken on trunk builds since bug 317375
Comment 4•18 years ago
|
||
Also, this happens both in Camino and Firefox Mac.
Updated•18 years ago
|
Summary: Javascript opacity for text in <div> element is broken, no problem in Firefox, Mozilla, Camino 1.0b2 → Javascript opacity for text in <div> element is broken, no problem on branch
Comment 5•18 years ago
|
||
roc, per stuart, this was caused by fallout from your patch in bug 317375. -> core
Assignee: mikepinkerton → nobody
Component: General → Layout
Product: Camino → Core
QA Contact: layout
Updated•18 years ago
|
Assignee | ||
Comment 6•18 years ago
|
||
This WFM on Linux.
Assignee | ||
Comment 7•18 years ago
|
||
Could this be a Mac-only regression unrelated to 317375?
Comment 8•18 years ago
|
||
(In reply to comment #7) > Could this be a Mac-only regression unrelated to 317375? > Mac-only, probably. I posted about the opacity problem(s) in the forums, and people using Windows (XP) didn't have problems with my testfile, such as attachment 209911 [details] (https://bugzilla.mozilla.org/attachment.cgi?id=209911) to bug 324940. Those opacity problems started with the 20050126 builds (after bug 317375 landed).
Comment 9•18 years ago
|
||
Please attach a testcase to the bug itself instead of just linking to it?
Comment 10•18 years ago
|
||
Two identical boxes, in the second one, the spans have opacity set to 0.8. The spans disappear. Hover to get them back.
Comment 11•18 years ago
|
||
*** Bug 325920 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 12•18 years ago
|
||
Errr ... while out hiking today I realized what the problem is. The old nsViewManager::Refresh code peeked into the display list to see if 'opacity' was in use, and if so, turned on double-buffering on the Mac. I removed that, so currently the Mac doesn't turn on double-buffering and 'opacity' doesn't work. The problem is that restoring that approach is hard, because the view manager no longer has access to the display list, and the display list isn't even built when we need to make the double-buffering decision, and changing that would result in a grotesque interface. The other problem is that this will just go away when the cairo/Thebes builds start using Quartz to do all rendering. OTOH I don't want to leave Mac 'opacity' broken in the non-cairo builds. Hmm
Assignee | ||
Comment 13•18 years ago
|
||
Someone please test this to see if it fixes Mac.
Assignee | ||
Comment 14•18 years ago
|
||
If that patch works, then this can be reviewed. The basic idea is to fail nsPresShell::Paint when we can't draw with opacity. The view manager takes failure as a cue to retry the paint with the backbuffer on. This is a little slower than what we were doing before, but only on Mac, on pages with 'opacity', and until cairo/Thebes rendering takes over.
Updated•18 years ago
|
Summary: Javascript opacity for text in <div> element is broken, no problem on branch → JavaScript opacity for text in <div> element is broken, no problem on branch
Comment 15•18 years ago
|
||
The patch in comment 13 doesn't apply for me (many failed hunks), so I can't test it easily.
Updated•18 years ago
|
Flags: blocking1.9a1?
Flags: blocking1.9a1+
Flags: blocking1.8.1+
Assignee | ||
Comment 16•18 years ago
|
||
This is not present on branch and does not block 1.8.1. Jesse, I'll update the patch. It's a bit unfortunate that no-one tried it right away.
Flags: blocking1.8.1+
Updated•18 years ago
|
Flags: blocking1.9a1+ → blocking1.9a1?
Comment 17•18 years ago
|
||
It turns out that this is the same issue that is breaking Litmus on Mac (bug 328215). This is currently breaking anything that uses moo.fx's MultiFadeSize divs. If you can post an updated patch, I'd be happy to test it out on my end.
Comment 18•18 years ago
|
||
I think this is breaking Tinderbox "star" messages on Mac too.
Assignee | ||
Comment 19•18 years ago
|
||
This is a simpler fix that leaves opacity disabled but tries to draw the element opaquely instead of just failing to draw it entirely. Please try it on Mac.
Attachment #210819 -
Attachment is obsolete: true
Attachment #210820 -
Attachment is obsolete: true
Comment 20•18 years ago
|
||
attachment 212995 [details] [diff] [review] doesn't appear to have any effect at all for me, in Firefox trunk - things with opacity aren't drawn, and the NS_WARNINGs never warn.
Assignee | ||
Comment 21•18 years ago
|
||
Would you mind stepping through nsDisplayOpacity, or just stuffing some printfs or whatever you use on Mac in there, and telling me what happens on a simple testcase on Mac?
Comment 22•18 years ago
|
||
The return val of blender->Blend is just 0 (as suggested in comment 20) when opacity is 0.8 and others are bounds = {x = 705, y = 4927, width = 1590, height = 450} damageRectInPixels = {x = 47, y = 328, width = 106, height = 30} buffers->mWhiteCX = { mRawPtr = 0x218d88a0 } buffers->mBlackCX = { mRawPtr = 0x218d8b70 }
Comment 23•18 years ago
|
||
Hmm... something odd might be happening. I tried to force nsDisplayWrapList::Paint, but the situation does not change.
Assignee | ||
Comment 24•18 years ago
|
||
Hmm. If you force nsDisplayOpacity::Paint to just call nsDisplayWrapList::Paint(aBuilder, aCtx, aDirtyRect) and do nothing else, that should definitely work.
Comment 25•18 years ago
|
||
Sorry, my comment 23 was incorrect. I just didin't know I had to make in layout instead of layout/base. Forcing nsDisplayWrapList::Paint (if (NS_FAILED(rv)) -> if (1) after blender->Blend) "works."
Assignee | ||
Comment 26•18 years ago
|
||
Makoto-san, would you mind producing a patch that just uses #ifdef XP_MAC to replace the entired !MOZ_CAIRO_GFX path with a call to nsDisplayWrapList::Paint?
Comment 27•18 years ago
|
||
Toddling cairo-cocoa build exhibit this problem too, but let's puzzle it out later (maybe in another bug).
Attachment #213959 -
Flags: review?(roc)
Assignee | ||
Comment 28•18 years ago
|
||
Comment on attachment 213959 [details] [diff] [review] mac workaround No, we need to keep the existing non-MOZ_CAIRO_GFX code for non-Mac platforms
Attachment #213959 -
Flags: review?(roc) → review-
Comment 29•18 years ago
|
||
Oops, you meant this one?
Attachment #213959 -
Attachment is obsolete: true
Attachment #213964 -
Flags: review?(roc)
Assignee | ||
Comment 30•18 years ago
|
||
Comment on attachment 213964 [details] [diff] [review] Preserve non-mac non-cairo path yes --- assuming you've tested it on Mac and it works. If you don't have CVS access, find someone on IRC to check it in for you, or I'll do it on Monday.
Attachment #213964 -
Flags: superreview+
Attachment #213964 -
Flags: review?(roc)
Attachment #213964 -
Flags: review+
Comment 31•18 years ago
|
||
checked-in to trunk. Should we open this until perfect fix?
Assignee | ||
Comment 32•18 years ago
|
||
The correct fix will happen when we turn on cairo for Mac.
Comment 33•18 years ago
|
||
*** Bug 326768 has been marked as a duplicate of this bug. ***
Comment 34•18 years ago
|
||
*** Bug 301752 has been marked as a duplicate of this bug. ***
Updated•18 years ago
|
Flags: blocking1.9a1? → blocking1.9+
*** Bug 358270 has been marked as a duplicate of this bug. ***
Whiteboard: [blocking1.9a1+]
Assignee | ||
Comment 36•18 years ago
|
||
I don't think this blocks 1.9a1. We've hacked around the problem of stuff not appearing. Opacity will be fixed for real when cairo gets turned on on Mac.
Sorry, didn't realize that this was noncairo.
Whiteboard: [blocking1.9a1+]
Comment 38•18 years ago
|
||
This bug's testcase doesn't display properly in cocoa-cairo builds: some text that should be "behind" the boxes is shown "in front of" the boxes when they have opacity: 1. Should I file a new bug for that?
Comment 39•18 years ago
|
||
(In reply to comment #38) > This bug's testcase doesn't display properly in cocoa-cairo builds: some text > that should be "behind" the boxes is shown "in front of" the boxes when they > have opacity: 1. Should I file a new bug for that? That is the correct painting order. Check it out in other browsers. The box (span) with 'opacity' set to anything but '1' is sort of pulled forward and painted on top of everything else.
Comment 40•18 years ago
|
||
Really? That seems strange -- I'd expect opacity changes to be linear.
Comment 41•18 years ago
|
||
(In reply to comment #40) A message by D.Baron to the CSS-D mailing list explains how 'opacity' acts: http://archivist.incutio.com/viewlist/css-discuss/69890 And see http://www.w3.org/TR/CSS21/zindex.html
Comment 42•18 years ago
|
||
*** Bug 346738 has been marked as a duplicate of this bug. ***
Comment 43•17 years ago
|
||
(In reply to comment #34) > *** Bug 301752 has been marked as a duplicate of this bug. *** > Just wanted to add myself to the CC. Test case match of bug 301752. Causes http://www.dynamicdrive.com/dynamicindex17/rsstickerajax/ fading ticker problems.
Comment 44•17 years ago
|
||
Well, if this is waiting for Cairo to be FIXED, it's certainly fixed now that it's not possible to build without Cairo.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Comment 45•17 years ago
|
||
Cairo being turned on is a precondition. It's necessary, but are you sure it's sufficient? As in, did you actually test? Reopening, but my apologies in advance if you did.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Comment 46•17 years ago
|
||
Only the tinderbox registry/who.cgi popups multiple times every day, and the color fade for tab overflow every tab I've opened since Mano turned it back on once we got opacity back, and the testcase from comment 10 just before I resolved it. But, you're right: I have no idea why this was left open once the workaround landed, and no idea why it was left open after cairo-cocoa landed, so I've got no business resolving it.
Comment 47•17 years ago
|
||
Hey, good to hear. ;)
Status: REOPENED → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•