Closed Bug 100652 Opened 23 years ago Closed 23 years ago

hidden, absolutely positioned iframes mask repainting

Categories

(Core Graveyard :: GFX, defect)

Product:
Core Graveyard
Component:
GFX
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.6

People

(Reporter: emartind2, Assigned: kmcclusk)

References

Details

(Keywords: topembed, Whiteboard: [DIGBug] Checked into trunk and 094 branch)

Attachments

(2 files)

Reporter-produced testcase modified to make the iframe wider
1.58 KB, text/html
Details
Patch to prevent the invalidation of views with hidden widgets
820 bytes, patch
roc
: review+
attinasi
: superreview+
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
BuildID:    2001091703

If a hidden iframe is over the same space as a radio button, clicking on the 
radio buttons will not get repainted. This happens with any element that is 
covered by a hidden, absolutely positioned iframe.

Reproducible: Always
Steps to Reproduce:
1.Put in a table with 3 radio buttons.
2.Put a hidden iframe over the radio buttons.
3.Try and click on the buttons. 
4.To see that the buttons have received the events, minimize the browser, and 
then bring it back up. Your click will have been repainted at this point.

Actual Results:  see step 4.

Expected Results:  While the iframe is hidden, all repainting should be done 
immediately.

Below is my test html
---------------------------------------------------
<html>
<body >
<form>
<table width="100%" border="0" style="z-index:10;background-color:#08216B">
      <tr>
        <td style="color:#FFFFFF">1st</td>
        <td>
          <input type="radio" name="default_email" value="0">
        </td>
      </tr>
      <tr>
        <td style="color:#FFFFFF">2nd </td>
        <td>
          <input type="radio" name="default_email" value="1">
        </td>
      </tr>
      <tr>
        <td style="color:#FFFFFF"> 3rd</td>
        <td>
          <input type="radio" name="default_email" value="2">
        </td>
      </tr>
</table>
</form>

<iframe id=hiddenIframe marginHeight=1 marginWidth=1 frameborder=1 scrolling=no
style="position:absolute; background-color:#000000; visibility:hidden; top:0px;
left:0px; height:100px; width:300; z-index:-1"></iframe>
<br><br><br>

<p>Hit TOGGLE to see where the hidden iframe is located</p><br>
<p>Hit Z-index to change the iframe's z-index style attribute from 0 to -1. The
table's z-index is 10.</p>
<a href="javascript:toggle();">TOGGLE</a>&nbsp;&nbsp;
<a href="javascript:z();">Z-index</a>
</body>
<script>
function toggle() {
var hidden;
if (document.all )
        hidden = document.all['hiddenIframe'];
else
        hidden = document.getElementById('hiddenIframe');

if (hidden.style.visibility == 'visible'){
        hidden.style.visibility = 'hidden';
} else {
        hidden.style.visibility = 'visible';
}
}

function z() {
var hidden;
if (document.all )
        hidden = document.all['hiddenIframe'];
else
        hidden = document.getElementById('hiddenIframe');

if (hidden.style.zIndex == -1){
        hidden.style.zIndex = 0;
} else {
        hidden.style.zIndex = -1;
}
}
</script>

</html>
------------------------------------------------------------
Whiteboard: DIGBug
Over to Compositor.
Assignee: jst → kmcclusk
Component: DOM Content Models → Compositor
QA Contact: lchiang → petersen
Confirming Win2k 20010924 with attachment 50961 [details]
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.6
adding topembed
Keywords: topembed
The problem was in nsViewManager::UpdateAllCoveringWidgets. The existing code
assumed that if a view had a widget and the view completely covered the
invalidated rect then the widget for the covering view would be the only widget
invalidated. It did account for the case when the view's widget was hidden. In
that case the view's widget should be removed from consideration and the widget
of the view's parent should be invalidated instead.
Whiteboard: DIGBug → [DIGBug] Waiting for review/super-review
Comment on attachment 53985 [details] [diff] [review]
Patch to prevent the invalidation of  views with hidden widgets

r=roc+moz
Attachment #53985 - Flags: review+
Comment on attachment 53985 [details] [diff] [review]
Patch to prevent the invalidation of  views with hidden widgets

sr=attinasi
Attachment #53985 - Flags: superreview+
Whiteboard: [DIGBug] Waiting for review/super-review → [DIGBug] Read to check in
DIG Engineer:  Will this fix make it into the 6.2 branch and the CS 7.0 client?
Checked patch 53985 into trunk
Whiteboard: [DIGBug] Read to check in → [DIGBug] Checked into trunk
*** Bug 90963 has been marked as a duplicate of this bug. ***
Resolving as fixed. Added edt0.9.4 keyword
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Keywords: edt0.9.4
Resolution: --- → FIXED
Peterson: Can you verify that this has been fixed on the trunk? Thanks!
Marking verified in the Nov 1 (2001-11-01-03) trunk build. Tested on Windows ME.
Status: RESOLVED → VERIFIED
please check into the 0.9.4 branch, and mark w/ the "fixed0.9.4" keyword when it
lands there.
Keywords: edt0.9.4 → edt0.9.4+
Fix checked into 094 branch
Keywords: fixed0.9.4
Whiteboard: [DIGBug] Checked into trunk → [DIGBug] Checked into trunk and 094 branch
Verified on 0.9.4 build (2002-01-14-23-0.9.4ec).
Keywords: verified0.9.4
Keywords: fixed0.9.4
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: