Open Bug 654643 Opened 13 years ago Updated 2 years ago

Double-clicking a re-sizable frame border causes the whole window to act like the Firefox main bar.

Categories

(Core :: Web Painting, defect)

Product:
Core
Component:
Web Painting
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

Status:
REOPENED

People

(Reporter: jrose, Unassigned)

References

(
URL
)

Details

(Keywords: regression)

Attachments

(1 file)

sample html
71 bytes, text/html
Details 
User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.1) Gecko/20100101 Firefox/4.0.1

If I had to guess, it might have something to do with Firefox 4's new fancy status of having the tabs integrated into the title bar.  When I double click one of these borders, the elements in all the frames on the page become untouchable and all clicks are basically treated as though they were clicks on the window title bar.  If I double click anywhere on the window, the window maximizes.  If I click and drag similarly, the window can be moved around.  This happens every time on this specific site.

Reproducible: Always

Steps to Reproduce:
1. Double click on a resizable frame border.
That's all it takes.


At this point, the regular behavior can be restored simply by clicking both mouse buttons at the same time anywhere on the window.

Actual Results:  
copy-pasted:

The elements in all the frames on the page become untouchable and all clicks are basically treated as though they were clicks on the window title bar.  If I double click anywhere on the window, the window maximizes.  If I click and drag similarly, the window can be moved around.  This happens every time on this specific site.

Expected Results:  
Nothing special should happen and the page should remain viewable as normal.  This is how old versions of Firefox worked and how every other browser on the planet functions.

This web page isn't viewable without an account, so I'm including the page source which produces the same results even if it can't load any of the data:

<html><head><title>The Kingdom of Loathing</title></head><frameset id=rootset cols="4*,*"><frameset id=menuset rows="30,*"><frame name=menupane src="topmenu.php" scrolling=no></frame><frameset id=mainset cols="200,*"><frame name=charpane src="charpane.php"></frame><frame name=mainpane src="main.php"></frame></frameset></frameset><frame name=chatpane src="chatlaunch.php"></frame></frameset></html>
Attached file sample html — 
Confirmed on
http://hg.mozilla.org/mozilla-central/rev/86248f7209b7
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110503 Firefox/6.0a1 ID:20110503030636
http://hg.mozilla.org/mozilla-aurora/rev/308693ad3772
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:5.0a2) Gecko/20110503 Firefox/5.0a2 ID:20110503042003
http://hg.mozilla.org/releases/mozilla-2.0/rev/f43e15acc6ca
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0.2pre) Gecko/20110503 Firefox/4.0.2pre ID:20110503030640
Status: UNCONFIRMED → NEW
Ever confirmed: true
Regression window(cached m-c hourly):
Works:
http://hg.mozilla.org/mozilla-central/rev/01fa971e62ee
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827190212
Fails:
http://hg.mozilla.org/mozilla-central/rev/0886ad6e6aaa
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827190555
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01fa971e62ee&tochange=0886ad6e6aaa


In local build:
build from 7804b5cf4313 : fails
build from 4722b491cd0d : works
build from be60f89d06ba : works
build from 8ac6b17eab3e : works
landing of Bug 130078 trigger the problem.
Blocks: 130078
Component: Shell Integration → Layout: View Rendering
Keywords: regression
Product: Firefox → Core
QA Contact: shell.integration → layout.view-rendering
Version: unspecified → Trunk
(In reply to comment #3)
> Random guess: does deleting this code
> http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrameSetFrame.cpp?force=1#1546
> fix the problem?

//    // Update the view immediately (make drag appear snappier)
//    nsIViewManager* vm = aPresContext->GetPresShell()->GetViewManager();
//    if (vm) {
//      nsIView* root = vm->GetRootView();
//      if (root) {
//        vm->UpdateView(root, NS_VMREFRESH_IMMEDIATE);
//      }
//    }
  }
}

I tried local build and it seems nothing changed.
Ok thanks for checking that!. Then I'm not sure what it might be.
As of really recently, this bug appears to be fixed.  Nifty.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
(In reply to comment #6)
> As of really recently, this bug appears to be fixed.  Nifty.
It is reproducible on recent nightly.
http://hg.mozilla.org/mozilla-central/rev/a8f07cad55e2
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a1) Gecko/20110508 Firefox/6.0a1 ID:20110508030616

Not yet fixed. > REOPENED
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Component: Layout: View Rendering → Layout: Web Painting
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: