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)

PowerPC
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: hanzov69, Assigned: roc)

References

()

Details

(Keywords: regression)

Attachments

(3 files, 3 obsolete files)

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
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
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
This is the same issue as in bug 324940.

Basically, 'opacity' is broken on trunk builds since bug 317375
Also, this happens both in Camino and Firefox Mac.
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
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
Assignee: nobody → roc
Blocks: 317375
Flags: blocking1.9a1?
Could this be a Mac-only regression unrelated to 317375?
(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).
Please attach a testcase to the bug itself instead of just linking to it?
Two identical boxes, in the second one, the spans have opacity set to 0.8. The spans disappear. Hover to get them back.
*** Bug 325920 has been marked as a duplicate of this bug. ***
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
Blocks: 324940
Attached patch possible patch (obsolete) — Splinter Review
Someone please test this to see if it fixes Mac.
Attached patch diff -w for review (obsolete) — Splinter Review
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.
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
The patch in comment 13 doesn't apply for me (many failed hunks), so I can't test it easily.
Flags: blocking1.9a1?
Flags: blocking1.9a1+
Flags: blocking1.8.1+
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+
Flags: blocking1.9a1+ → blocking1.9a1?
Blocks: 328215
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. 
I think this is breaking Tinderbox "star" messages on Mac too.
Attached patch simpler fixSplinter Review
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
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.
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?
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 }
Hmm... something odd might be happening. I tried to force nsDisplayWrapList::Paint, but the situation does not change.
Hmm. If you force nsDisplayOpacity::Paint to just call nsDisplayWrapList::Paint(aBuilder, aCtx, aDirtyRect) and do nothing else, that should definitely work.
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."
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?
Attached patch mac workaround (obsolete) — Splinter Review
Toddling cairo-cocoa build exhibit this problem too, but let's puzzle it out later (maybe in another bug).
Attachment #213959 - Flags: review?(roc)
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-
Oops, you meant this one?
Attachment #213959 - Attachment is obsolete: true
Attachment #213964 - Flags: review?(roc)
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+
checked-in to trunk. Should we open this until perfect fix?
The correct fix will happen when we turn on cairo for Mac.
Depends on: 323934
*** Bug 326768 has been marked as a duplicate of this bug. ***
*** Bug 301752 has been marked as a duplicate of this bug. ***
Blocks: 346738
Flags: blocking1.9a1? → blocking1.9+
*** Bug 358270 has been marked as a duplicate of this bug. ***
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+]
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?
(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.

Really?  That seems strange -- I'd expect opacity changes to be linear.
(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 

*** Bug 346738 has been marked as a duplicate of this bug. ***
(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.
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
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 → ---
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.
Hey, good to hear.  ;)
Status: REOPENED → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.