340989 - Mozilla trunk works with calendar.google.com wrong

Status: RESOLVED DUPLICATE of bug 340798

(Core :: Layout, defect)

Description

[Oleg Romashin (:romaxa)]

Build Latest mozilla trunk with xulrunner configuration

open page calendar.google.com
click on any cell in calendar.

Expected outcome:
Popup element looks normal

Actual outcome:
Popup element appears behind main table.
Screenshot in attachment.


Console warnings:
CSS Error (http://www.google.com/calendar/render?pli=1 :0.15): Unknown property 'text-overflow'.  Declaration dropped.
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 846
WARNING: recurring into frame construction: 'mPresContext->mLayoutPhaseCount[eLayoutPhase_FrameC] == 0', file ../../dist/include/layout/nsPresContext.h, line 846

Comment 1

[Oleg Romashin (:romaxa)]

Attachment: Wrong popup

Comment 2

[:Gavin Sharp [email: [e-mail]]]

Do you have a regression range?

Comment 3

[Oleg Romashin (:romaxa)]

(In reply to comment #2)
> Do you have a regression range?
> 

Hm what you mean?

I checkout it on 20060604 there it works fine, but 20060609 it works wrong...

Comment 4

[:Gavin Sharp [email: [e-mail]]]

A regression range is what you just gave, like "works in 20060604 trunk but not 20060609 trunk". The smaller the regression range, the easier it is to find the bug that caused the regression by looking at checkin logs.

Comment 5

[Oleg Romashin (:romaxa)]

(In reply to comment #4)
> A regression range is what you just gave, like "works in 20060604 trunk but not
> 20060609 trunk". The smaller the regression range, the easier it is to find the
> bug that caused the regression by looking at checkin logs.
> 

Problems appears here:
diff in nsFrame.cpp between 2006-06-08 07.00.00 and 2006-06-08 05.00.00

@@ -1287,14 +1287,19 @@
   if (aChild->GetStateBits() & NS_FRAME_IS_UNFLOWABLE)
     return NS_OK;

-  // XXX we really need IsFrameOfType() here
   nsIAtom* childType = aChild->GetType();
+  const nsStyleDisplay* disp = aChild->GetStyleDisplay();
   // PR_TRUE if this is a real or pseudo stacking context
   PRBool pseudoStackingContext =
     (aFlags & DISPLAY_CHILD_FORCE_PSEUDO_STACKING_CONTEXT) != 0;
+  // XXX we REALLY need a "are you an inline-block sort of thing?" here!!!
   if ((aFlags & DISPLAY_CHILD_INLINE) &&
       (aChild->IsContainingBlock() ||
-       childType == nsLayoutAtoms::listControlFrame)) {
+       childType == nsLayoutAtoms::tableOuterFrame ||
+       childType == nsLayoutAtoms::listControlFrame ||
+       disp->mDisplay == NS_STYLE_DISPLAY_INLINE_BOX ||
+       disp->mDisplay == NS_STYLE_DISPLAY_INLINE_GRID ||
+       disp->mDisplay == NS_STYLE_DISPLAY_INLINE_STACK)) {
     // child is a block or table-like frame in an inline context, i.e.,
     // it acts like inline-block or inline-table. Therefore it is a
     // pseudo-stacking-context.
@@ -1360,7 +1365,6 @@
   }
 #endif

-  const nsStyleDisplay* disp = aChild->GetStyleDisplay();
   PRBool isComposited = disp->mOpacity != 1.0f;
   PRBool isPositioned = disp->IsPositioned();
   if (isComposited || isPositioned) {



It is enough? ;)

If Change:
   nsIAtom* childType = aChild->GetType();
-  const nsStyleDisplay* disp = aChild->GetStyleDisplay();
+  const nsStyleDisplay* disp1 = aChild->GetStyleDisplay();
+       disp1->mDisplay == NS_STYLE_DISPLAY_INLINE_BOX ||
+       disp1->mDisplay == NS_STYLE_DISPLAY_INLINE_GRID ||
+       disp1->mDisplay == NS_STYLE_DISPLAY_INLINE_STACK)) {


- const nsStyleDisplay* disp = aChild->GetStyleDisplay();
+ const nsStyleDisplay* disp = aChild->GetStyleDisplay();
  PRBool isComposited = disp->mOpacity != 1.0f;

It works fine

Comment 6

[Oleg Romashin (:romaxa)]

Attachment: BUGFIX patch, tested

I think it should fix this problem

Comment 7

[Oleg Romashin (:romaxa)]

Attachment: BUGFIX patch, tested

I think it should fix this problem

Comment 8

[:Gavin Sharp [email: [e-mail]]]

Comment on attachment 225145 [details] [diff] [review]
BUGFIX patch, tested

I am not a layout peer. Please try "roc@oc" or "dbaron@moz".

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Duplicate of bug 340798?

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** This bug has been marked as a duplicate of 340798 ***

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

romaxa: thanks for making a patch. Unfortunately I got to it first :-). Better luck next time! :-)