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)
Tracking
()
REOPENED
People
(Reporter: jrose, Unassigned)
References
()
Details
(Keywords: regression)
Attachments
(1 file)
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>
Comment 1•13 years ago
|
||
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
Updated•13 years ago
|
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 2•13 years ago
|
||
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
Comment 3•13 years ago
|
||
Random guess: does deleting this code http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFrameSetFrame.cpp?force=1#1546 fix the problem?
Comment 4•13 years ago
|
||
(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.
Comment 5•13 years ago
|
||
Ok thanks for checking that!. Then I'm not sure what it might be.
Reporter | ||
Comment 6•13 years ago
|
||
As of really recently, this bug appears to be fixed. Nifty.
Reporter | ||
Updated•13 years ago
|
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Comment 7•13 years ago
|
||
(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 → ---
Assignee | ||
Updated•6 years ago
|
Component: Layout: View Rendering → Layout: Web Painting
Updated•2 years ago
|
Severity: minor → S4
You need to log in
before you can comment on or make changes to this bug.
Description
•