aura: Add fullscreen/popups to RenderWidgetHostViewAura.

aura: Add fullscreen/popups to RenderWidgetHostViewAura.

This also makes aura::DesktopHostLinux avoid generating Char
events when not appropriate, which avoids a problem that I
observed where arrow keys were moving <select> selections two
spaces instead of one.

There still appears to be an issue with the Enter key getting
double-counted in <select> popups, though (but if we avoid
sending a Char event for it, things like <textarea> break),
and fullscreen Flash windows aren't getting updated.

BUG=99757, 101899, 101848
TEST=manual

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=108008

[Daniel Erat, 2011-10-27 22:37:19]

There are still issues with this change, but it seems like an improvement. :-/ 
Hironori-san, does the WM_CHAR part seem reasonable?

[sadrul, 2011-10-27 22:47:19]

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:109:
window_->SetParent(aura::Desktop::GetInstance());
Shouldn't this be parented to the default container in the shell?

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:385: if
(event->key_code() == ui::VKEY_ESCAPE) {
This is only when 'IsPopup'?

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/web_input_event_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/web_input_event_aura.cc:69: const gfx::Point
screen_point =
For the screen-location, it would be nice if we can extract this from the
base::NativeEvent. It should be possible on X11, is it possible on windows?

[Ben Goodger (Google), 2011-10-27 22:56:10]

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:101:
static_cast<RenderWidgetHostViewAura*>(parent_host_view)->window_);
It seems like these should be parented to the menu container. Reason is if you
just do this we will not send events outside the bounds of the parent.
Perhaps we need to stow some state on window_ in this case and then
SetParent(NULL) to give the shell a chance to do this parenting. The popup would
be a transient of the parent_host_view's window though.

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:109:
window_->SetParent(aura::Desktop::GetInstance());
The menu container, to be exact.

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:299: //
TODO(derat): Don't hardcode this?
leave NOTIMPLEMENTED() if there is something here you don't want to see
production.

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:386:
host_->Shutdown();
Side note: seems odd to me that the view has to do this. Isn't this handled by
webkit somewhere?

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/web_input_event_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/web_input_event_aura.cc:69: const gfx::Point
screen_point =
We can assume "screen" to mean "client position within the desktop host's
window".

This is probably required for web compat.

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/web_input_event_aura.h (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/web_input_event_aura.h:21: aura::Window* window);
rename window to target. It becomes self documenting at that point - the target
is the window the event was sent to. This implies that the event is in target
coords too also.

[Daniel Erat, 2011-10-28 00:53:13]

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:101:
static_cast<RenderWidgetHostViewAura*>(parent_host_view)->window_);
On 2011/10/27 22:56:11, Ben Goodger (Google) wrote:
> It seems like these should be parented to the menu container. Reason is if you
> just do this we will not send events outside the bounds of the parent.
> Perhaps we need to stow some state on window_ in this case and then
> SetParent(NULL) to give the shell a chance to do this parenting. The popup
would
> be a transient of the parent_host_view's window though.

Done.  I think that it's not a transient since this class is just creating an
aura::Window directly instead of going through the NativeWidgetAura path,
though.

I used TYPE_MENU for this.  Is TYPE_POPUP more appropriate?  (The two use
different containers, and I believe that we only use InitPopup() for menus.)

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:109:
window_->SetParent(aura::Desktop::GetInstance());
On 2011/10/27 22:56:11, Ben Goodger (Google) wrote:
> The menu container, to be exact.

I used TYPE_POPUP here, but that just gets treated as a regular window and
stuffed in the default container by the shell (which means that things like the
status area remain on top of it).  Should it instead be TYPE_MENU?  (If so,
TYPE_MENU should probably be renamed.)

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:299: //
TODO(derat): Don't hardcode this?
On 2011/10/27 22:56:11, Ben Goodger (Google) wrote:
> leave NOTIMPLEMENTED() if there is something here you don't want to see
> production.

I'm okay with this being in production.  It'd ideally be exposed by
aura::Desktop or aura::Window, I think, which'd probably need to get it from the
layer...

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:385: if
(event->key_code() == ui::VKEY_ESCAPE) {
On 2011/10/27 22:47:20, sadrul wrote:
> This is only when 'IsPopup'?

Whoops, yeah (fullscreen, though).  Sorry for missing that; fixed.

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:386:
host_->Shutdown();
On 2011/10/27 22:56:11, Ben Goodger (Google) wrote:
> Side note: seems odd to me that the view has to do this. Isn't this handled by
> webkit somewhere?

It's needed for Pepper Flash.

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/web_input_event_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/web_input_event_aura.cc:69: const gfx::Point
screen_point =
On 2011/10/27 22:47:20, sadrul wrote:
> For the screen-location, it would be nice if we can extract this from the
> base::NativeEvent. It should be possible on X11, is it possible on windows?

Done.

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
File content/browser/renderer_host/web_input_event_aura.h (right):

http://codereview.chromium.org/8417008/diff/2001/content/browser/renderer_hos...
content/browser/renderer_host/web_input_event_aura.h:21: aura::Window* window);
On 2011/10/27 22:56:11, Ben Goodger (Google) wrote:
> rename window to target. It becomes self documenting at that point - the
target
> is the window the event was sent to. This implies that the event is in target
> coords too also.

Done.

[Hironori Bono, 2011-10-28 05:10:11]

Greetings,

My comment is just for your information.

Regards,

Hironori Bono

http://codereview.chromium.org/8417008/diff/3016/ui/aura/desktop_host_linux.cc
File ui/aura/desktop_host_linux.cc (right):

http://codereview.chromium.org/8417008/diff/3016/ui/aura/desktop_host_linux.c...
ui/aura/desktop_host_linux.cc:187: bool
ShouldSendCharEventForKeyboardCode(ui::KeyboardCode keycode) {
nit: we also need true when we type graphic-character keys or numpad keys (i.e.
VKEY_OEM_1,...,VKEY_OEM_7, VKEY_OEM_COMMA, VKEY_OEM_PERIOD, VKEY_OEM_PLUS,
VKEY_OEM_MINUS, VKEY_NUMPAD_0,...,VKEY_NUMPAD_9, VKEY_MULTIPLY, VKEY_ADD,
VKEY_SUBTRACT, VKEY_DECIMAL, VKEY_DIVIDE, etc.)?

[Daniel Erat, 2011-10-28 14:56:16]

Thanks, I've updated the list of keys that generate char events as you
recommended (plus VKEY_OEM_102).

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:107:
window_->SetProperty(
Thoughts about whether this should be exposed by a method in aura::Window?  My
main concern is that it'll get confused with Window::type_; the current progress
wrt getting rid of that is unclear to me.

[Ben Goodger (Google), 2011-10-28 16:27:52]

BTW the reason I mentioned transience is you will want the popups to be
destroyed when the RWHVA that owns them is destroyed. Or is this handled by WK
somehow?

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:107:
window_->SetProperty(
I would like to get rid of Window::type_, mostly because type-specific
functionality is something we should try and keep out of Window (normally
type-specific behavior is restricted to things like stacking, parenting, etc,
all of which are done in the shell.)

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:109:
reinterpret_cast<void*>(views::Widget::InitParams::TYPE_MENU));
However, you can't use views types here, because src/content does not depend on
src/views.

Despite wanting to get rid of Window::type_ above, I do wonder if we should
define some basic types in aura that users (like this code) can set.

This would resolve the DEPs issues. What do you think?

[Daniel Erat, 2011-10-28 17:04:25]

+oshima for his opinion here

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
File content/browser/renderer_host/render_widget_host_view_aura.cc (right):

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:107:
window_->SetProperty(
On 2011/10/28 16:27:53, Ben Goodger (Google) wrote:
> I would like to get rid of Window::type_, mostly because type-specific
> functionality is something we should try and keep out of Window (normally
> type-specific behavior is restricted to things like stacking, parenting, etc,
> all of which are done in the shell.)

I agree with the sentiment, but it seems like we still need some way for the
code that's creating these windows to pass a type to the shell so the shell
knows what to do with them.

http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
content/browser/renderer_host/render_widget_host_view_aura.cc:109:
reinterpret_cast<void*>(views::Widget::InitParams::TYPE_MENU));
On 2011/10/28 16:27:53, Ben Goodger (Google) wrote:
> However, you can't use views types here, because src/content does not depend
on
> src/views.
> 
> Despite wanting to get rid of Window::type_ above, I do wonder if we should
> define some basic types in aura that users (like this code) can set.
> 
> This would resolve the DEPs issues. What do you think?

Of the values currently in ui/aura/window_types.h, kWindowType_Control appears
to be the only one that's used, and just so that
NativeWidgetAura::InitNativeWidget() can ask Window::Init() to call
layer_->SetVisible(true).  It seems like that could be removed in favor of
adding an initially_visible param to Window::Init().

The duplication between views::Widget::InitParams::Type and whatever type would
live in aura::Window is problematic, though.  That being said, it looks like we
have effectively just two types of windows right now from the shell's
perspective (menu/tooltip and everything else), so maybe we could do what you're
suggesting.  It seems reasonable to me to put a few types in
ui/aura/window_types.h, make NativeWidgetAura set it appropriately based on the
widget's type, and make the shell check the Window's type instead of the
views::NativeWidgetAura::kWindowTypeKey property.

[oshima, 2011-10-28 17:42:23]

On 2011/10/28 17:04:25, Daniel Erat wrote:
> +oshima for his opinion here
> 
>
http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
> File content/browser/renderer_host/render_widget_host_view_aura.cc (right):
> 
>
http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
> content/browser/renderer_host/render_widget_host_view_aura.cc:107:
> window_->SetProperty(
> On 2011/10/28 16:27:53, Ben Goodger (Google) wrote:
> > I would like to get rid of Window::type_, mostly because type-specific
> > functionality is something we should try and keep out of Window (normally
> > type-specific behavior is restricted to things like stacking, parenting,
etc,
> > all of which are done in the shell.)
> 
> I agree with the sentiment, but it seems like we still need some way for the
> code that's creating these windows to pass a type to the shell so the shell
> knows what to do with them.
>
http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
> content/browser/renderer_host/render_widget_host_view_aura.cc:109:
> reinterpret_cast<void*>(views::Widget::InitParams::TYPE_MENU));
> On 2011/10/28 16:27:53, Ben Goodger (Google) wrote:
> > However, you can't use views types here, because src/content does not depend
> on
> > src/views.
> > 
> > Despite wanting to get rid of Window::type_ above, I do wonder if we should
> > define some basic types in aura that users (like this code) can set.
> > 
> > This would resolve the DEPs issues. What do you think?
> 
> Of the values currently in ui/aura/window_types.h, kWindowType_Control appears
> to be the only one that's used, and just so that
> NativeWidgetAura::InitNativeWidget() can ask Window::Init() to call
> layer_->SetVisible(true).  It seems like that could be removed in favor of
> adding an initially_visible param to Window::Init().
> 
> The duplication between views::Widget::InitParams::Type and whatever type
would
> live in aura::Window is problematic, though.  That being said, it looks like
we
> have effectively just two types of windows right now from the shell's
> perspective (menu/tooltip and everything else), so maybe we could do what
you're
> suggesting.

We may need another type/container for panel and applist.

  It seems reasonable to me to put a few types in
> ui/aura/window_types.h, make NativeWidgetAura set it appropriately based on
the
> widget's type, and make the shell check the Window's type instead of the
> views::NativeWidgetAura::kWindowTypeKey property.

Are you suggesting to use type_, instead of GetProperty? There are other
"properties" that currently defined in window (show_state, restore_bounds) that
I'm tying to move to property. I'd prefer type to use Get/SetProperty for
consistency reason if possible.
 That's being said, I like to keep key and value definitions in the same place
(when possible).
Varun just adde ui/aura/aura_constants.h, so how about moving key and values to
there?

[Ben Goodger (Google), 2011-10-28 17:51:45]

> The duplication between views::Widget::InitParams::Type and whatever type
would
> live in aura::Window is problematic, though.

I don't see this as being problematic in that the views types control behavior
on the views side as well. It is best to consider views to be a distinct entity
from aura with its own rules. Some of the views Widget types may map to aura
types, but there may be additional ones, or types that reflect to an aura type +
some properties set on an aura window for example. This is because views has to
implement its type system against various window managers incl win32.

[Ben Goodger (Google), 2011-10-28 17:54:14]

On 2011/10/28 17:42:23, oshima wrote:
> Are you suggesting to use type_, instead of GetProperty? There are other
> "properties" that currently defined in window (show_state, restore_bounds)
that
> I'm tying to move to property. I'd prefer type to use Get/SetProperty for
> consistency reason if possible.
>  That's being said, I like to keep key and value definitions in the same place
> (when possible).
> Varun just adde ui/aura/aura_constants.h, so how about moving key and values
to
> there?

This contradicts my concern that we will end up with type-specific logic in
aura::Window. Are there technical ways we can avoid ending up in this situation?

[oshima, 2011-10-28 17:54:35]

On 2011/10/28 17:42:23, oshima wrote:
> On 2011/10/28 17:04:25, Daniel Erat wrote:
> > +oshima for his opinion here
> > 
> >
>
http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
> > File content/browser/renderer_host/render_widget_host_view_aura.cc (right):
> > 
> >
>
http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
> > content/browser/renderer_host/render_widget_host_view_aura.cc:107:
> > window_->SetProperty(
> > On 2011/10/28 16:27:53, Ben Goodger (Google) wrote:
> > > I would like to get rid of Window::type_, mostly because type-specific
> > > functionality is something we should try and keep out of Window (normally
> > > type-specific behavior is restricted to things like stacking, parenting,
> etc,
> > > all of which are done in the shell.)
> > 
> > I agree with the sentiment, but it seems like we still need some way for the
> > code that's creating these windows to pass a type to the shell so the shell
> > knows what to do with them.
> >
>
http://codereview.chromium.org/8417008/diff/6010/content/browser/renderer_hos...
> > content/browser/renderer_host/render_widget_host_view_aura.cc:109:
> > reinterpret_cast<void*>(views::Widget::InitParams::TYPE_MENU));
> > On 2011/10/28 16:27:53, Ben Goodger (Google) wrote:
> > > However, you can't use views types here, because src/content does not
depend
> > on
> > > src/views.
> > > 
> > > Despite wanting to get rid of Window::type_ above, I do wonder if we
should
> > > define some basic types in aura that users (like this code) can set.
> > > 
> > > This would resolve the DEPs issues. What do you think?
> > 
> > Of the values currently in ui/aura/window_types.h, kWindowType_Control
appears
> > to be the only one that's used, and just so that
> > NativeWidgetAura::InitNativeWidget() can ask Window::Init() to call
> > layer_->SetVisible(true).  It seems like that could be removed in favor of
> > adding an initially_visible param to Window::Init().
> > 
> > The duplication between views::Widget::InitParams::Type and whatever type
> would
> > live in aura::Window is problematic, though.  That being said, it looks like
> we
> > have effectively just two types of windows right now from the shell's
> > perspective (menu/tooltip and everything else), so maybe we could do what
> you're
> > suggesting.
> 
> We may need another type/container for panel and applist.
> 
>   It seems reasonable to me to put a few types in
> > ui/aura/window_types.h, make NativeWidgetAura set it appropriately based on
> the
> > widget's type, and make the shell check the Window's type instead of the
> > views::NativeWidgetAura::kWindowTypeKey property.
> 
> Are you suggesting to use type_, instead of GetProperty? There are other
> "properties" that currently defined in window (show_state, restore_bounds)
that
> I'm tying to move to property. I'd prefer type to use Get/SetProperty for
> consistency reason if possible.
>  That's being said, I like to keep key and value definitions in the same place
> (when possible).
> Varun just adde ui/aura/aura_constants.h, so how about moving key and values
to
> there?

Forgot to mention. I agree to define window types that shell/views can share
somewhere
in ui/aura, and my preference is in aura_constants.h

[oshima, 2011-10-28 17:57:29]

On 2011/10/28 17:54:14, Ben Goodger (Google) wrote:
> On 2011/10/28 17:42:23, oshima wrote:
> > Are you suggesting to use type_, instead of GetProperty? There are other
> > "properties" that currently defined in window (show_state, restore_bounds)
> that
> > I'm tying to move to property. I'd prefer type to use Get/SetProperty for
> > consistency reason if possible.
> >  That's being said, I like to keep key and value definitions in the same
place
> > (when possible).
> > Varun just adde ui/aura/aura_constants.h, so how about moving key and values
> to
> > there?
> 
> This contradicts my concern that we will end up with type-specific logic in
> aura::Window. Are there technical ways we can avoid ending up in this
situation?

What I was thinking is that we only put key/values in ui/aura/aura_constants and
keep actual code/logic that uses them in views/shell. Sorry if it wasn't clear.

[Ben Goodger (Google), 2011-10-28 17:59:06]

On 2011/10/28 17:57:29, oshima wrote:
> What I was thinking is that we only put key/values in ui/aura/aura_constants
and
> keep actual code/logic that uses them in views/shell. Sorry if it wasn't
clear.

I understand that - that's sort of what we have now... but aura::Window still
has a type_ field, and with that being there, it becomes tempting for an
innocent cl to use it and implement shell-like functionality in aura::Window.

[Ben Goodger (Google), 2011-10-28 18:00:52]

On 2011/10/28 17:59:06, Ben Goodger (Google) wrote:
> I understand that - that's sort of what we have now... but aura::Window still
> has a type_ field, and with that being there, it becomes tempting for an
> innocent cl to use it and implement shell-like functionality in aura::Window.

In the absence of technical means, as long as you, derat, sky and myself are on
the same page wrt type_'s intended use (as something that should be as opaque to
aura::Window as possible), I am OK with this approach. It is most likely that
one of us four would be writing code in this area or reviewing it, so if we
share this understanding we can prevent badness. :-)

[Daniel Erat, 2011-10-28 22:17:20]

Another look?

http://codereview.chromium.org/8417008/diff/2005/ui/aura/window_types.h
File ui/aura/window_types.h (right):

http://codereview.chromium.org/8417008/diff/2005/ui/aura/window_types.h#newco...
ui/aura/window_types.h:15: WINDOW_TYPE_NORMAL,
Naming suggestions welcome for all of these.  I'm trying to go with a pretty
minimal set at first; I assume that this list will change frequently.  All that
the shell seems to need at present is:

- NORMAL: window should be laid out as usual
- POPUP: window shouldn't be laid out
- MENU/TOOLTIP: window should be added to menu/tooltip container instead of
default container

So technically, we could get away with just three values here.

[Ben Goodger (Google), 2011-10-31 17:59:48]

http://codereview.chromium.org/8417008/diff/2006/views/widget/native_widget_a...
File views/widget/native_widget_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2006/views/widget/native_widget_a...
views/widget/native_widget_aura.cc:99: ui::Layer::LAYER_HAS_TEXTURE :
these lines should be indent 2 more spaces

http://codereview.chromium.org/8417008/diff/2006/views/widget/native_widget_a...
views/widget/native_widget_aura.cc:102: aura::Window::LAYER_INITIALLY_VISIBLE :
It really pains to add an extra parameter to every Init() to cover this one
case. Maybe we could just SetVisible(true) after this line instead?

[Daniel Erat, 2011-10-31 19:48:18]

http://codereview.chromium.org/8417008/diff/2006/views/widget/native_widget_a...
File views/widget/native_widget_aura.cc (right):

http://codereview.chromium.org/8417008/diff/2006/views/widget/native_widget_a...
views/widget/native_widget_aura.cc:99: ui::Layer::LAYER_HAS_TEXTURE :
On 2011/10/31 17:59:48, Ben Goodger (Google) wrote:
> these lines should be indent 2 more spaces

I always go back and forth between 2 and 4 in the ternary-within-param-list
case.  Switched to 4.

http://codereview.chromium.org/8417008/diff/2006/views/widget/native_widget_a...
views/widget/native_widget_aura.cc:102: aura::Window::LAYER_INITIALLY_VISIBLE :
On 2011/10/31 17:59:48, Ben Goodger (Google) wrote:
> It really pains to add an extra parameter to every Init() to cover this one
> case. Maybe we could just SetVisible(true) after this line instead?

It pained me to update all the callers too. :-P  I've removed the parameter and
have made NativeWidgetAura::InitNativeWidget() call Window::Show() instead for
controls.

[Ben Goodger (Google), 2011-10-31 19:50:22]

lgtm