After refreshing outlook.office.com today, I noticed that my addins all have 18px of margin above them in the read and compose views. The margin is on the 'commands-353' class (which is also the 'ms-Panel-commands' element). This element is a sibling of 'ms-Panel-contentInner' and is pushing the addin inner content down causing it to overflow off of the page and adding a scrollbar.
I work on an addin development team and this is affecting our addin. I am wondering if this is a known issue that will be fixed, or if there is a workaround that we should plan to implement for our addin.
Screenshot of The HTML
Screenshot of the margin above the addin
Related
I am trying to replace the quick launch menu on the left hand side of just one library in a SharePoint 2013 site. Instead, I would like to show just the library metadata navigation.
Is there a way to do this without modifying the master? If not, is there a way to move the navigation above the menu? I tried some code in the script editor I found on a different site, but I just made everything disappear! I also tried just removing the menu, but the entire bar disappeared including the metadata navigation.
To anyone who finds this question, adding the below snippet to a script editor webpart on the library page solved my issue:
<style>
.ms-core-listmenu-verticalBox{ DISPLAY: none }
</style>
So I really hate the way chrome extension development works so I decided to make a regular webapp and use an iframe in my extension. Everything works fine, except for the dimensions of the website and the scrolling on the extension/site.
When developing the site, I knew I was going to use an iframe so I used percentages when formatting the site, for the most part I used 100% on most divs and textboxes. Anyway, the problem I am facing is that the scroll is extremely wonky on the extension for instance this is a picture of my extension with 400px height:
400x400. Everything looks fine.
and here is my extension with 800px height:
400x800. Scroll appears.
Why is the scroll appearing if I am merely making the extension longer? It doesn't make sense to me.
Any idea why this is happening?
There is a limit on the size of the popup window. I don't know the exact dimensions though.
You cannot increase the size of the document past it, scroll will appear.
For some reason i am not able to enter any text in inputtext in dhtml environment. The same is working fine in swf10 environment.
When i hover over the input text i observed that the cursor is not changing to selector. It looks as if the onmouseover event of inputtext is not getting fired.
Has anyone come across this kind of issue in openlaszlo dhtml envrironment?
I am using OpenLaszlo 4.9, Windows 7 and the browser is Firefox 15.0
I found a bug report in jira http://jira.openlaszlo.org/jira/browse/LPP-9934.
Please suggest any ideas to overcome this issue/
The problem you are seeing is probably connected to the way OpenLaszlo replicates the behavior of clicking through Sprites or visual elements in the Flash runtime for the DHTML/JavaScript runtime. Until recently browsers didn't support that kind of functionality directly. Therefore the OpenLaszlo team had to use a workaround, which is described in detail in this comment on LPP-5447.
Clickdivs exist to have independent control over clickable sprites,
without interference from regular divs. They are placed in a separate
copy of the regular lzdiv sprite hierarchy so we have more control.
This also provides a place to put focused inputtext divs so they are
in the foreground and clicking/dragging to edit works properly.
The clickdiv functionality seems to be broken from time to time with browser updates or due to regressions. In 2012 some improvements to the DHTML runtime click-through functionality were done, using newer browser features in Firefox (which now allows to click through div elements using the CSS style pointer-events). Since the clickdiv functionality is part of the LFC, fixing that functionality in your application is not advised.
You can test if the inputtext works by tabbing through the components until your inputtext element has the focus and start typing. If the text can be entered as expected, but you cannot click the component with your mouse to select it, it's definitely a clickdiv problem.
Update: Tested with OpenLaszlo 4.9.0 and various browsers
I've tested with OpenLaszlo 4.9.0, DHTML runtime and IE9, Firefox as well as Chrome, using the test case attached to LPP-9934: All browsers show that specific bug behavior. If the bug has not been filed, please file a JIRA bug.
I've created a web part page which contains visio drawing in sharepoint site. Now I want to show shape data when the mouse hover on specific shapes, instead of clicking "Toggle the visibility of shape information pane".
e.g. When mouse hovers at one employee image, more detailed information which is included in "Shape Data" can pop up, showing "Name:XXX, ID:XXX, Age:XXX..."
I've tried to add "Comment" in "shape sheet", but the hover over effect only works in Visio Design Mode. It does not work after I integrated the drawing in sharepoint webpart.
Also, I tried another approach by saving visio drawing as htm webpage. However, the data will not be dynamically updated in that way.
How could I achieve this function? Do I need to use javascript? If so, how could I integrate javascript to the webpage I already created with visio drawing?
This will walk you through the process.
Creating an Office Plan ECMAScript Mashup Drawing in Visio 2010 to Display in SharePoint Server 2010
In SharePoint 2007, there's a top nav that the user can hover over, which reveals a dropdown menu of subitems. When they remove their mouse from the dropdown, it disappears, but only after a short delay. This can cause problems, as if people are trying to click a link on the page somewhere, but the nav menu hasn't hidden itself yet, they'll accidentally click it instead. This is compounded with the fact that the menu appearing in the first place is delayed as well, so right before they mouse over the link on the page they actually want to click, the menu will suddenly appear and intercept their click when they weren't meaning to.
I've poked at core.js at some suspect areas, but can't seem to nail it down. Any thoughts?
This is the normal behaviour of SharePoint. This control is the asp:Menu control of ASP.Net 2.0 and the only thing you can do is customized the MasterPage or the DefaultPage of your Site.
If you change the core.js file of "layouts" folder you'll lose Microsoft support, so take care about change any of the file from this folder.
I recommend that you modify the existent control or create a new one and put it in this position of the MasterPage.
This bit of CSS will fix it. I just had the same thing in sharepoint 2010 and this was all that was required to make the list disappear as soon as you roll off:
li.hover-off>ul
{
display:none;
}
The way it works is when you hover over an item in the nav it adds a css class called "hover" and as soon as your mouse leaves the area it changes the class to "hover-off" for 1 second before removing it completely. This CSS will hide the unordered list directly below the list item that has the class "hover-off" thus hiding the flyout as soon as your mouse leaves the parent.