Closed
Bug 937298
Opened 12 years ago
Closed 12 years ago
deCOM nsIFrame::GetOffsetFromView
Categories
(Core :: Layout, defect, P4)
Tracking
()
RESOLVED
FIXED
mozilla28
People
(Reporter: dholbert, Assigned: dholbert)
Details
(Whiteboard: [qa-])
Attachments
(2 files, 2 obsolete files)
|
4.45 KB,
patch
|
dholbert
:
review+
|
Details | Diff | Splinter Review |
|
3.11 KB,
patch
|
MatsPalmgren_bugz
:
review+
|
Details | Diff | Splinter Review |
nsIFrame::GetOffsetFromView is declared as NS_IMETHOD.
It only has one implementation (in nsFrame.cpp), which always returns NS_OK, and none of the callers bother to check the return value anyway. So the return value is useless.
We should just make it return void, to reflect reality.
| Assignee | ||
Comment 1•12 years ago
|
||
(Note that both of GetOffsetFromView()'s parameters are really outparams. It's possible that one should be promoted to be the actual return value, but I won't do that here, to keep this patch simple.)
| Assignee | ||
Comment 2•12 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #0)
> and none of the callers bother to check the return value anyway
Actually, there's one caller that bothers to check, in nsFrame.cpp, but the check is useless since it will never fail (since the function always returns NS_OK).
So, this patch just drops that check.
Comment 3•12 years ago
|
||
Comment on attachment 830396 [details] [diff] [review]
fix v1: Make function return void instead of NS_OK (and drop one useless failure-check)
>+nsFrame::GetOffsetFromView(nsPoint& aOffset,
>+ nsView** aView) const
Looks like it fits on one line. Ditto the declaration in nsIFrame.h
r=mats
Attachment #830396 -
Flags: review?(matspal) → review+
| Assignee | ||
Comment 4•12 years ago
|
||
Actually, instead of dropping the useless error-check, I should probably fix it to check what it almost certainly wants to be checking.
As noted in the documentation for GetOffsetFromView(), this function indicates an error by returning null in its "view" outparam. (This happens if it internally walks off the top of the frame tree, accumulating offsets, without finding any frame with a view along the way.)
So, the currently-useless error check in nsFrame.cpp probably wants to null-check |view| and fail if it's null. Note that that's what we do elsewhere, e.g.:
http://mxr.mozilla.org/mozilla-central/source/content/events/src/nsContentEventHandler.cpp#1015
Attachment #830396 -
Attachment is obsolete: true
Attachment #830404 -
Flags: review?(matspal)
| Assignee | ||
Updated•12 years ago
|
Attachment #830404 -
Attachment description: fix v2: Make function return void instead of NS_OK (and drop one useless failure-check) → fix v2: Make function return void instead of NS_OK (and fix one useless failure-check)
Updated•12 years ago
|
Attachment #830404 -
Flags: review?(matspal) → review+
Comment 5•12 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #1)
> (Note that both of GetOffsetFromView()'s parameters are really outparams.
> It's possible that one should be promoted to be the actual return value, but
> I won't do that here, to keep this patch simple.)
Also, since there's only one implementation, could we move it to nsIFrame and
make it non-virtual? It looks like the implementation just use stuff that is
available in nsIFrame. We could add private declarations in non-nsFrame
classes that inherits nsIFrame to prevent accidental use there, if we feel
it's important.
| Assignee | ||
Comment 6•12 years ago
|
||
(In reply to Mats Palmgren (:mats) from comment #3)
> >+nsFrame::GetOffsetFromView(nsPoint& aOffset,
> >+ nsView** aView) const
>
> Looks like it fits on one line. Ditto the declaration in nsIFrame.h
Good point -- I'll fix that up in the existing patch.
(In reply to Mats Palmgren (:mats) from comment #5)
> Also, since there's only one implementation, could we move it to nsIFrame and
> make it non-virtual?
I thought about that, too -- I'll do that in a second patch here.
> We could add private declarations in non-nsFrame
> classes that inherits nsIFrame to prevent accidental use there, if we feel
> it's important.
I don't think that's worth worrying about. (Do you know of any non-nsFrame concrete classes that inherit from nsIFrame? AFAICT nsBox is the only direct child of nsIFrame, and nsFrame is the only direct child of nsBox, so there shouldn't be any other non-nsFrame things that inherit from nsIFrame.)
Comment 7•12 years ago
|
||
It seems I was mistaken because I can't find any. So nothing to worry about.
| Assignee | ||
Comment 8•12 years ago
|
||
Attachment #830404 -
Attachment is obsolete: true
Attachment #830494 -
Flags: review+
| Assignee | ||
Comment 9•12 years ago
|
||
Attachment #830495 -
Flags: review?(matspal)
| Assignee | ||
Updated•12 years ago
|
Attachment #830495 -
Attachment description: part 2: de-virtualize GetOffsetFromView → part 2: de-virtualize GetOffsetFromView and put its sole impl on nsIFrame
Updated•12 years ago
|
Attachment #830495 -
Flags: review?(matspal) → review+
| Assignee | ||
Comment 10•12 years ago
|
||
Try run (Linux/B2G only): https://tbpl.mozilla.org/?tree=Try&rev=66b0de7ec022
Landed:
https://hg.mozilla.org/integration/mozilla-inbound/rev/3a2da11f68be
https://hg.mozilla.org/integration/mozilla-inbound/rev/7ca4093ff578
Flags: in-testsuite-
| Assignee | ||
Updated•12 years ago
|
Priority: -- → P4
Comment 11•12 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/3a2da11f68be
https://hg.mozilla.org/mozilla-central/rev/7ca4093ff578
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
Updated•12 years ago
|
Whiteboard: [qa-]
You need to log in
before you can comment on or make changes to this bug.
Description
•