205165 - a href link fails to work until window is resized

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Grzywacz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030510 Mozilla Firebird/0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4b) Gecko/20030510 Mozilla Firebird/0.6

At http://msn.espn.go.com/main.html, they occasionally place a large Flash
banner at the top that resizes itself to a smaller area after a few seconds of
advertisements. After the resize however, almost all the links on the page fail
to be operational, and sometimes "random" layout errors are even visible (ones
that aren't present when this Flash window isn't resizing itself.)
I'm using the latest CVS Phoenix browser (20030510), but is reproducable in
Mozilla 1.3 as well.

Reproducible: Always

Steps to Reproduce:
1. Go to espn.com
2.
3.

Actual Results:  
The page loads, the flash animation does its thing, and when it resizes, the
links no longer work (A few along the top are still functional, but all the
loser ones are not).

Expected Results:  
The links should still be clickable.

This is a Gentoo Linux box running kernel 2.4.20

Comment 1

[Geoff Leach]

The problem occurs for me using Mozilla 1.4b ...

about:buildconfig

--enable-svg --enable-crypto --enable-default-toolkit=gtk2 --disable-toolkit-gtk
--disable-toolkit-qt --enable-xft --enable-freetype2 --enable-cpp-rtti
--enable-cpp-exceptions --enable-extensions --with-system-jpeg
--with-system-zlib --with-system-png --with-system-mng

Comment 2

[Stefan [:stefanh]]

*** Bug 205187 has been marked as a duplicate of this bug. ***

Comment 3

[Stefan [:stefanh]]

*** Bug 205182 has been marked as a duplicate of this bug. ***

Comment 4

[Stefan [:stefanh]]

Marking "NEW" based on the dupes.

Comment 5

[Ari]

This bug does not depend on flash because I can reproduce it on Camino Build ID:
2003050904 without the flash plug-in installed. This is probably a layout bug,
not a plug-in bug.

It's pretty major though because it makes the page nearly unusable. Large parts
of the page aren't painted correctly and most links don't work.

This is not a recent regression because I can reproduce it in the Mozilla 1.3
release.

Comment 6

[Olivier Cahagne]

*** Bug 205239 has been marked as a duplicate of this bug. ***

Comment 7

[Hermann Schwab]

I don´t think it is the flash, I could produce crashes with the menue.
Posting here what I wanted to post in bug 205239, but got mid-air collision:

http://espn.go.com/main.html
CRASHING Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4b) Gecko/20030509

reproducible:
at the left side there are menues, hover over 'More Sports', and a submenu opens.
You can open and close the submenue as often as you want to, but the moment you
are hovering over one of the entries of the submenue, ie. 1st entry: 'Olympic
Sports', mozilla crashes, Talkback and DocWatson are coming up.

TB19985436Q, TB19985660E, TB19985909G

DocWatson Stacksummary gives 7 adresses GKLAYOUT.DLL:.txt+0xd921a .. 0x15d77c,
then 4 adresses GKWIDGET.DLL.txt+0xee8 / 4919 / 4d03 / 14b2
then KERNEL32.DLL:_FREQASM+0x263b
then KERNEL32.DLL:.txt+0x1b2e7
then KERNEL(03):2737 and USER(1e):3d76, USER(1e):0000, USER(1e):392d

rendering of the page seems to be ok, when it is rendered.
I suppose reporter wants to see a collapsing ad at the start,
I don´t know how it should look.

Comment 8

[Olivier Cahagne]

Hermann, I just filed bug 205245 on the crash issue.

Comment 9

[Stefan [:stefanh]]

*** Bug 205242 has been marked as a duplicate of this bug. ***

Comment 10

[Andrew Schultz]

*** Bug 205266 has been marked as a duplicate of this bug. ***

Comment 11

[Josh Birnbaum]

*** Bug 205286 has been marked as a duplicate of this bug. ***

Comment 12

[Joseph Ross]

Attachment: testcase that shows that bug is not related to flash

I created a testcase which shows that this bug does not relate to flash at all,
but rather javascript. I am not a javascript expert (or even proficient in it)
so perhaps someone else can work off of mine and make a better testcase.

In the html file attached you should see 4 lines that say: visible after
movement, visble before movement, see no flash needed, and this link should
work after movement. Then the text will move and you should only see 3 lines.
The link works before the movement, but not after. It should work both times.

Comment 13

[Peter Lubczynski]

-->dom events

Comment 14

[David Bradley]

FWIW, resizing the window causes the links to work and scrolling to paint
properly.  Bug 205263 mentions that it doesn't paint when you scroll. Seems to
be all tied to the same problem.

Comment 15

[Joseph Ross]

While creating the testcase, I found that every single time that you couldn't
click on the link, the screen was also not repainted while scrolling. If you
could click a link, the screen would also be repainted. Thus, they are related.

Comment 16

[Eric A. Meyer (dead account)]

I got in touch with a guy at ESPN.com and he was able to provide me with
testcases that both triggered the bug and avoided it.  The one that avoides the
repaint problem is the same as the triggering testcase, except it has
differences in the whitespace around a <script> element.  They're somewhat large
but may be helpful, so I'll attach them.

Comment 17

[Eric A. Meyer (dead account)]

Attachment: ESPN-derived testcase that triggers painting bug

Comment 18

[Eric A. Meyer (dead account)]

Attachment: ESPN-derived testcase that avoids painting bug

From the e-mail I got from ESPN:

The only difference is that there is a carriage return before and after the
log.go.com script block in the "good" page.

Comment 19

[Eric A. Meyer (dead account)]

Adding nsbeta1 and topembed keywords, and raising severity to major.

Comment 20

[Andrew Schultz]

Attachment: reduced testcase

this has the minimum to see this bug.  With linux trunk 20030515, nothing is
displayed.  The text "This text should be visible and be selectable" should be
visible (and selectable).

Resizing the window fixes the problem.
As Eric indicated, putting "foo" on the same line as the opening <div> fixes
the problem and putting the opening <div> on a separate line from the previous
<div></div> also fixes it.

Comment 21

[Andrew Schultz]

not events.
==> layout?

Comment 22

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

Perhaps dependent on bug 197581?  I don't think so, though, since the absolutely
positioned element ought to have its own view, although I could be wrong.

Comment 23

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

You got it, David.

Without actually digging, here's my *guess* as to what's happening:
The absolute DIV does have its own view and that view should have the right
position and size. However, since the overflow for the relative DIV is
incorrect, the view for the relative DIV is incorrectly sized (to 0,0 probably).
This violates the view system invariant that views contain their children, and
this violation means that the view system will not paint or send events to the
absolute DIV.

Comment 24

[Samir Gehani]

adt: nsbeta1+/adt1

Reassigning to Kevin who would know the appropriate owner.

Comment 25

[Juan José Mata]

EDT 5/19: topembed+

Comment 26

[Kevin McCluskey (gone)]

views after page load 
----------------------

docshell=035843F0
03918400 (widget=039182D4[3] pos={0,0,9180,4350}) {0,0,9180,4350} z=0 vis=1 opc=
1.000 tran=0 clientData=00F1E9E0 <
  0392E4A0 (widget=0392E374[2] pos={0,0,9180,4350}) {0,0,9180,4350} z=0 vis=1 op
c=1.000 tran=1 clientData=00F1EE74 <
    0392E220 {0,0,9180,4350} z=0 vis=1 opc=1.000 tran=0 clientData=00F1EAEC <
      03925110 {120,120,8940,0} z=0 vis=1 opc=1.000 tran=1 clientData=00F3D39C <

        03925080 {0,0,3930,300} z=0 vis=1 opc=1.000 tran=1 clientData=00F3D530 <

        >
      >
    >
  >
  0392E560 {9180,0,0,0} z=0 vis=0 opc=1.000 tran=0 clientData=00F1F2CC <
  >
  0392E6E0 {0,4350,0,0} z=0 vis=0 opc=1.000 tran=0 clientData=00F1F0E0 <
  >
>

views after resizing window

docshell=035843F0
03918400 (widget=039182D4[3] pos={0,0,9315,4455}) {0,0,9315,4455} z=0 vis=1 opc=
1.000 tran=0 clientData=00F1E9E0 <
  0392E4A0 (widget=0392E374[2] pos={0,0,9315,4455}) {0,0,9315,4455} z=0 vis=1 op
c=1.000 tran=1 clientData=00F1EE74 <
    0392E220 {0,0,9315,4455} z=0 vis=1 opc=1.000 tran=0 clientData=00F1EAEC <
      03925110 {120,120,3930,300} z=0 vis=1 opc=1.000 tran=1 clientData=00F3D39C
 <
        03925080 {0,0,3930,300} z=0 vis=1 opc=1.000 tran=1 clientData=00F3D530 <

        >
      >
    >
  >
  0392E560 {9315,0,0,0} z=0 vis=0 opc=1.000 tran=0 clientData=00F1F2CC <
  >
  0392E6E0 {0,4455,0,0} z=0 vis=0 opc=1.000 tran=0 clientData=00F1F0E0 <
  >
>

The following view has 0 height after the page load
   
03925110 {120,120,8940,0} z=0 vis=1 opc=1.000 tran=1 clientData=00F3D39C <

After resizing this view is set to the correct height.

03925110 {120,120,3930,300} z=0 vis=1 opc=1.000 tran=1 clientData=00F3D39C

Comment 27

[Kevin McCluskey (gone)]

Frame dump using reduced test case
==================================

Viewport(-1)@00F19160 [view=038CD450] {0,0,10725,6000} [state=00042004] [content
=00000000] [sc=00F1909C]<
  GfxScroll(html)(-1)@00F194D8 {0,0,10725,6000} [state=81c40004] [content=038E1C
10] [sc=00F192E8]<
    ScrollPortFrame(html)(-1)@00F195F4 [view=03913D50] next=00F19860 {0,0,10725,
6000} [state=80c42014] [content=038E1C10] [sc=00F19B08]<
      Canvas(html)(-1)@00F1926C [view=038E0200] {0,0,10725,6000} [state=00042000
] [content=038E1C10] [sc=00F19C98]<
        Area(html)(-1)@00F23780 {0,0,10725,6000} [state=00c4000c] sc=00F23754(i=
1,b=1)<
          line 00F23A00: count=1 state=inline,clean,prevmarginclean,not impacted
,not wrapped,nobr[0x1000] {0,0,0,0} <
            Text(1)@00F238E0[0,4,T]  next=00F2398C {0,0,0,0} [state=51000024] sc
=00F23888<
              "\n   "
            >
          >
          line 00F23A30: count=1 state=block,clean,prevmarginclean,not impacted,
not wrapped,nobr[0x1004] bm=120 {120,120,10485,0} ca={120,120,10485,300} <
            Block(body)(2)@00F2398C {120,120,10485,0} [state=0004000c] sc=00F239
20(i=3,b=2)<
              line 00F242A0: count=1 state=inline,clean,prevmarginclean,not impa
cted,not wrapped,nobr[0x1000] {0,0,0,0} <
                Text(0)@00F23BC8[0,8,T]  next=00F23CDC {0,0,0,0} [state=51000024
] sc=00F23B9C<
                  "\n\n      "
                >
              >
              line 00F242D0: count=1 state=block,clean,prevmarginclean,not impac
ted,not wrapped,nobr[0x1004] {0,0,10485,0} <
                Block(div)(1)@00F23CDC next=00F23E20 {0,0,10485,0} [state=000000
04] sc=00F23C34(i=0,b=0)<
                >
              >
              line 00F24330: count=1 state=inline,clean,prevmarginclean,not impa
cted,not wrapped,nobr[0x1000] {0,0,0,0} <
                Text(3)@00F23E20[0,8,T]  next=00F23F34 {0,0,0,0} [state=51000024
] sc=00F23B9C<
                  "\n\n      "
                >
              >
              line 00F24360: count=1 state=block,clean,prevmarginclean,not impac
ted,not wrapped,nobr[0x1004] {0,0,10485,0} ca={0,0,3930,300} <
                Area(div)(4)@00F23F34 [view=0390E4B0] next=00F24260 {0,0,10485,0
 <== ******THIS IS THE DIV WITH THE WRONG SIZE*****


} [state=0004200c] sc=00F23E8C(i=1,b=0)<
                  line 00F24230: count=3 state=inline,clean,prevmarginclean,not
impacted,not wrapped,nobr[0x3000] {0,0,0,0} <
                    Text(0)@00F23FB4[0,10,T]  next=00F241B8 {0,0,0,0} [state=510
00024] sc=00F23F88<
                      "\n         "
                    >
                    Placeholder(div)(1)@00F241B8 {0,0,0,0} [state=00000004] outO
fFlowFrame=Area(div)(1)@00F240C8
                    Text(2)@00F241F0[0,7,T]  {0,0,0,0} [state=51000024] sc=00F23
F88<
                      "\n      "
                    >
                  >
                  Absolute-list<
                    Area(div)(1)@00F240C8 [view=0390E250] {0,0,3930,300} [state=
00c02104] sc=00F24020(i=1,b=0)<
                      line 00F24188: count=1 state=inline,clean,prevmarginclean,
not impacted,not wrapped,nobr[0x1000] {0,0,3930,300} <
                        Text(0)@00F24148[0,45,T]  {0,7,3930,285} [state=40000024
] sc=00F2411C<
                          "This text should be visible and be selectable"
                        >
                      >
                    >
                  >
                >
              >
              line 00F24390: count=1 state=inline,clean,prevmarginclean,not impa
cted,not wrapped,nobr[0x1000] {0,0,0,0} <
                Text(5)@00F24260[0,5,T]  {0,0,0,0} [state=51000024] sc=00F23B9C<

                  "\n\n   "
                >
              >
            >
          >
        >
      >
    >
    ScrollbarFrame(scrollbar)(-1)@00F19860 [view=03913F90] next=00F19A4C {0,6000
,10725,0} [state=80c82024] [content=039158A0] [sc=00F197AC]<>
    ScrollbarFrame(scrollbar)(-1)@00F19A4C [view=03913E10] {10725,0,0,6000} [sta
te=80882024] [content=039153F0] [sc=00F19998]<>
  >
>

Comment 28

[Kevin McCluskey (gone)]

Area(div)(4)@00F23F34 [view=0390E4B0] next=00F24260 {0,0,10485,0) owns the view
that has the incorrect initial size.

After manually sizing the window, the div's dimensions do *not* change but it's
view is correctly updated, so the text appears.

Looks like the layout code which calculates the views dimensions is not
calculating the view's height correctly under a very specific circumstance where
we have a relatively positioned element which is preceeded by a element which
has been set to display:none through the onload handler. If I set it to
display:none using an inline style attribute it works. 

Maybe its failing to generate an incremental reflow when the onload handler sets
an element to display:none?

Roc, Kin, John: Any ideas?

Comment 29

[kinmoz]

Just an fyi, I applied bernd's patch for bug 197581 and it doesn't help with
this specific problem.

I poked around in the debugger a bit and noticed that after the initial reflow,
the view for the relative div initially has the dimensions that is derived from
the union of the relative div frame's rect and it's overflow area (which  gives
it both  a width and height) but after the onLoad fires and the 2nd div in the
file is hidden, nsContainerFrame::SyncFrameViewAfterReflow() gets triggered as
the result of nsBlockFrame::SlideLine() getting called, and
SyncFrameViewAfterReflow() resizes the relative div's view to the frame's rect
which has no height. I did verify in the debugger that if we just modified the
view's position, and left the view's dimensions alone, that things showed up
properly.

Comment 30

[Stefan [:stefanh]]

*** Bug 206760 has been marked as a duplicate of this bug. ***

Comment 31

[kinmoz]

Using bernd's patch, I was able to get all the testcases working with the
following modification to PlaceFrameView() in nsBlockFrame.cpp:


@@ -2841,7 +2815,8 @@
   nsIView*  view;
   aFrame->GetView(aPresContext, &view);
   if (view)
-    nsContainerFrame::SyncFrameViewAfterReflow(aPresContext, aFrame, view, nsnull);
+    nsContainerFrame::SyncFrameViewAfterReflow(aPresContext, aFrame, view,
+                      aFrame->GetOverflowAreaProperty(aPresContext, PR_FALSE));

   nsContainerFrame::PositionChildViews(aPresContext, aFrame);
 }

Comment 32

[Bernd]

-    nsContainerFrame::SyncFrameViewAfterReflow(aPresContext, aFrame, view, nsnull);
+    nsContainerFrame::SyncFrameViewAfterReflow(aPresContext, aFrame, view,
+                      aFrame->GetOverflowAreaProperty(aPresContext, PR_FALSE));

should be 

+    nsContainerFrame::SyncFrameViewAfterReflow(aPresContext, aFrame, view,
+                      aFrame->GetOverflowAreaProperty(aPresContext));

PR_FALSE is the default argument

Comment 33

[Chris Casciano]

*** Bug 207233 has been marked as a duplicate of this bug. ***

Comment 34

[Kevin McCluskey (gone)]

adt: bug 197581 needs to be checked in before the patch in this bug can be
checked in. bug 197581 is currently being reviewed.

jkeiser is looking taking this over. ETA 5/30

Comment 35

[chris hofmann]

getting on the 1.4 final radar

Comment 36

[John Keiser (jkeiser)]

r=me on comment 32

Comment 37

[kinmoz]

Attachment: Patch Rev 1

Now that bernd has landed his fix for bug 197581 on the TRUNK, here's a formal
patch for review based on comment 32.

Comment 38

[Anthony Carter]

How do I get the patch?

Comment 39

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

(In the long term, though, maybe the overflow area shouldn't be a parameter to
SyncFrameViewAfterReflow, and it should always do this, internally.)

Comment 40

[kinmoz]

I landed Patch Rev 1 on the TRUNK:

    mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.575

Comment 41

[kinmoz]

Comment on attachment 124746 [details] [diff] [review]
Patch Rev 1

Bug 197581 just got approval to land on the 1.4 branch ... Asking for approval
to land this one line patch in 1.4 too.

Comment 42

[(not reading, please use [e-mail] instead)]

Comment on attachment 124746 [details] [diff] [review]
Patch Rev 1

a=sspitzer

Comment 43

[kinmoz]

Fix checked into the MOZILLA_1_4_BRANCH:

    mozilla/layout/html/base/src/nsBlockFrame.cpp  revision 3.572.2.3

Comment 44

[esther]

Using branch build 20030610 on winxp and linux this is verified except for one
of the tests scenarios, someone want to comment on test sceanrio 20 (this is not
my usual area to test)
The original test scenario works OK
test case in comment 7 works OK
test case in comment 12 works OK
test case in comment 17 works OK
test case in comment 20 not OK (text not selectable)

Comment 45

[esther]

My mistake, scenario in comment 20 is selectable. 
Verified per testing the above scenarios.  If someone believes there should be
more testing for this bug test it and/or reopen it giving specific tests. 

Comment 46

[esther]

reopening, verified on branch only adding keyword verified1.4

Comment 47

[esther]

resolved fixed again adding keyword verified1.4

Comment 48

[Asa Dotzler [:asa]]

mozilla1.4 shipped. unsetting blocking1.4 request.

Comment 49

[Torben]

*** Bug 205263 has been marked as a duplicate of this bug. ***

Comment 50

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2004-06-30-08 and the testcase here
http://bugzilla.mozilla.org/attachment.cgi?id=123097&action=view as well as the
ESPN.com testcase on Windows XP.