Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fxShow is setting display:inline; in IE11 and Edge #310

Closed
adamdport opened this issue Jun 6, 2017 · 8 comments · Fixed by #374
Closed

fxShow is setting display:inline; in IE11 and Edge #310

adamdport opened this issue Jun 6, 2017 · 8 comments · Fixed by #374
Labels
has pr A PR has been created to address this issue P1 Urgent issue that should be resolved before the next re-lease
Milestone

Comments

@adamdport
Copy link

adamdport commented Jun 6, 2017

https://plnkr.co/edit/lF0h5ttXwFiOLrjIgKDr?p=preview

Discovered when using fxShow with md-menu-items. In the above plunkr, the last 4 items in the menu have fxShow on them. In IE11 and Edge, display:inline is applied to them, which ruins the layout.

@ThomasBurleson ThomasBurleson added the P1 Urgent issue that should be resolved before the next re-lease label Jun 22, 2017
@ThomasBurleson ThomasBurleson added this to the v2.0.0-beta.9 milestone Jun 22, 2017
@ThomasBurleson
Copy link
Contributor

ThomasBurleson commented Aug 8, 2017

The fxShow works fine in Chrome and Safari. Please try the updated Menu with fxShow Demo in IE/Edge.

Will re-open issue if problem persists.

Note: the demo uses the latest build published in https://github.com/angular/flex-layout-builds... this will be released to npm as Beta.9 very soon.

@adamdport
Copy link
Author

I tried your updated plunker in IE11 and it still seems broken. Was it working for you?

ie11

@ThomasBurleson
Copy link
Contributor

ThomasBurleson commented Aug 8, 2017

Yes on Mac OS (Chrome, Safari) it looks great. What is the display property value for Item #6 ?

screen shot 2017-08-08 at 2 48 32 pm

@adamdport
Copy link
Author

adamdport commented Aug 8, 2017

It's still display: inline and still only on IE11 and Edge.

If you don't have access to Windows for testing, Microsoft provides virtual machine images.

ie11

@ThomasBurleson
Copy link
Contributor

ThomasBurleson commented Aug 8, 2017

fxShow internally calls document.getComputedStyle('display').getPropertyValue() which finds the display:block defined in .mat-menu-item css class.

Material2 builds the CSS:

 .mat-menu-item {
  display: block;
  position: relative;
  line-height: 48px;
  height: 48px;
  padding: 0 16px;
   
  background: 0 0;
  color: rgba(0,0,0,.87);
  font-family: Roboto,"Helvetica Neue",sans-serif;
  font-size: 16px;
   
  -webkit-user-select: none;
  -moz-user-select: none;
  -ms-user-select: none;
  user-select: none;
  cursor: pointer;
  outline: 0;
  border: none;
  -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
  text-align: left;
  text-decoration: none;
}

I am confused regarding why this same code - when used in an IE11 browser - will calculate 'inline'.

@adamdport
Copy link
Author

I just added IDs to the non-fxShowed menu items and then ran window.getComputedStyle(document.getElementById('item-1')).getPropertyValue('display'). IE11 correctly computes "block". Not sure where flex-layout is getting inline from.

ie11block

@ThomasBurleson
Copy link
Contributor

Are you using the latest build from https://github.com/angular/flex-layout-builds/?
See https://github.com/angular/flex-layout-builds/blob/master/bundles/flex-layout.umd.js#L834-L835:

var immediateValue = _angular_platformBrowser.ɵgetDOM().getStyle(element, 'display');
                value = immediateValue || _angular_platformBrowser.ɵgetDOM().getComputedStyle(element).getPropertyValue('display');

Can you debug with a breakpoint at this point and see what the code is doing on IE11 browser?

ThomasBurleson added a commit that referenced this issue Aug 10, 2017
The Show/Hide directives would query the `display` style during construction. For elements constructed during `*ngFor`, calls to getComputedStyle() would incorrectly return “”. Query for styles in CSS stylesheets or inline styles would fail.

Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
@ThomasBurleson ThomasBurleson added has pr A PR has been created to address this issue and removed in-progress labels Aug 10, 2017
ThomasBurleson added a commit that referenced this issue Aug 10, 2017
The Show/Hide directives would query the `display` style during construction. For elements constructed during `*ngFor`, calls to getComputedStyle() would incorrectly return “”. Query for styles in CSS stylesheets or inline styles would fail.

Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
ThomasBurleson added a commit that referenced this issue Aug 11, 2017
The Show/Hide directives would query the `display` style during construction. For elements constructed during `*ngFor`, calls to getComputedStyle() would incorrectly return “”. Query for styles in CSS stylesheets or inline styles would fail.

Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
ThomasBurleson added a commit that referenced this issue Aug 11, 2017
Previously, the Show/Hide directives would query the `display` style during directive instantiation.

For elements instantiated during `*ngFor`, constructor calls to getComputedStyle() will incorrectly return “” due to failures in queries for styles in CSS stylesheets or inline styles. Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
ThomasBurleson added a commit that referenced this issue Aug 11, 2017
Previously, the Show/Hide directives would query the `display` style during directive instantiation.

For elements instantiated during `*ngFor`, constructor calls to getComputedStyle() will incorrectly return “” due to failures in queries for styles in CSS stylesheets or inline styles. Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
ThomasBurleson added a commit that referenced this issue Aug 11, 2017
Previously, the Show/Hide directives would query the `display` style during directive instantiation.

For elements instantiated during `*ngFor`, constructor calls to getComputedStyle() will incorrectly return “” due to failures in queries for styles in CSS stylesheets or inline styles. Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
ThomasBurleson added a commit that referenced this issue Aug 11, 2017
Previously, the Show/Hide directives would query the `display` style during directive instantiation.

For elements instantiated during `*ngFor`, constructor calls to getComputedStyle() will incorrectly return “” due to failures in queries for styles in CSS stylesheets or inline styles. Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
mmalerba pushed a commit that referenced this issue Aug 14, 2017
Previously, the Show/Hide directives would query the `display` style during directive instantiation.

For elements instantiated during `*ngFor`, constructor calls to getComputedStyle() will incorrectly return “” due to failures in queries for styles in CSS stylesheets or inline styles. Deferring these types of queries to the ngOnInit() lifecycle event, enables valid response to queries for both inline styles and stylesheets.

Fixes #310.
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 4, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
has pr A PR has been created to address this issue P1 Urgent issue that should be resolved before the next re-lease
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants