Last Comment Bug 683394 - Incorrect check for resizers in content
: Incorrect check for resizers in content
Product: Core
Classification: Components
Component: XP Toolkit/Widgets: XUL (show other bugs)
: Trunk
: All All
-- normal (vote)
: mozilla10
Assigned To: Neil Deakin
: Neil Deakin
Depends on:
Blocks: 680823 659338
  Show dependency treegraph
Reported: 2011-08-30 17:43 PDT by Neil Deakin
Modified: 2011-09-30 05:33 PDT (History)
1 user (show)
enndeakin: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

patch (3.15 KB, patch)
2011-08-30 17:43 PDT, Neil Deakin
no flags Details | Diff | Splinter Review
patch, moved doDefault lines (3.29 KB, patch)
2011-09-26 09:27 PDT, Neil Deakin
neil: review+
Details | Diff | Splinter Review

Description User image Neil Deakin 2011-08-30 17:43:32 PDT
Created attachment 557049 [details] [diff] [review]

The check in nsResizer.cpp is reversed and should block resizers in content. Also, native resizing should also be disabled in content.

The test will be posted to bug 659338.
Comment 1 User image 2011-09-26 08:14:33 PDT
Comment on attachment 557049 [details] [diff] [review]

>         }
>         else {
>+          doDefault = PR_FALSE;
>+          // If there is no window, then resizing isn't allowed.
>+          if (!window)
>+            break;
>         }
>-        doDefault = PR_FALSE;
I don't understand this change. In particular, you set doDefault to false even if there is no window, and fail to set it to false when you have content to resize. Or was that intentional?
Comment 2 User image Neil Deakin 2011-09-26 09:27:49 PDT
Created attachment 562452 [details] [diff] [review]
patch, moved doDefault lines

I moved the lines which set doDefault.

- the content block should have been setting it to false as well.
- I moved the second one after the window is not null check, although if there's no window, then it doesn't seem like it matters what happens here.
Comment 3 User image 2011-09-26 15:58:52 PDT
Comment on attachment 562452 [details] [diff] [review]
patch, moved doDefault lines

(In reply to comment #2)
> it doesn't seem like it matters what happens here.
I think we should only set doDefault to false if we process the click.
Comment 4 User image Matt Brubeck (:mbrubeck) 2011-09-29 20:43:09 PDT

Note You need to log in before you can comment on or make changes to this bug.