I am developing Outlook add-in and displaying a dialog with option displayInIframe: true and height and width parameters given. However I have experienced a problem using add-in in outlook.com via browser. Although it works good when screen has a standard proportion (width>height), it looks bad when I resize the window and make it narrow (height>width). Then, the content is resized and pushed to the side of the frame while the iframe itself stays with the same size.
The question is if I can do something with that or its a Outlook issue. If so, I would like to notify MSFT about it.
This is expected behavior of a web application, you cant do much except setting the min-width for your html page so that it does not look that bad.
you can do some css changes to make the page look better for height/width in question.
Related
I am making an add-in for outlook with dialogues using the displayDialogAsync method.
The problem is that if the main window has a small size the dialog will also be small, because the width and height is a percentage of the main window, and the content will not fit.
Is it possible to know the size of the main window, so I can use that to calculate how big the dialog should be?
I have tried with $(window).height() and $(window).width() but that returns the height and width of the box the add-in buttons are located in.
The display dialog only supports percentages, and the feature you requested is currently not part of the product. We track Outlook add-in feature requests on our user-voice page.
It looks like the feature you want has been requested by others already. Please upvote the existing request. Feature requests on user-voice are considered when we go through our planning process.
I have manually implemented the Flattr button to my site.
In Firefox (Windows) the "popout" covers the button so one can't press it.
Any other browser renders the popout in the correct place. Can someone confirm this? Or is it a conflict on my site?
Since you don't mention which site is yours I'm left to speculate on the reasons for this and if I do then I think it is that your body-element doesn't start at the top left of your browser and that therefor positioning of the popout fails due to browsers inability to correctly account for offset body elements.
We've had reports of people experiencing this problem in eg. WordPress where the admin-bar that's showed when a user is logged in pushes the entire site down 20 pixels or something and makes the position of the popout be of by 20 pixels. Could it be something similar for you - that you're logged in in Firefox and not in other browsers?
As far as I know there's no workaround for this limitation - eg. jQuery can't account for it either.
Good thing though: If your layout has a body with an offset or something else that makes the popout not work for you you can disable it by setting popout 0 in the settings of the button.
If I limit WebBrowser's height, and content is longer, scrollbar is created inside the WebBrowser (effectively, HTML page is long), similar to IE in WP7. This scrollbar behaves the way I want to - after swift swipe it continues to scroll, slowing down.
But if I place a div with a scrollbar in the WebBrowser content, this scrollbar behaves like regular HTML scrollbar, it does not keep scrolling after user stops touching the display.
Is there a way to make this work too ?
Thanks
No, not easily. The WP7 IE9 browser control supports the overflow:scroll CSS property that allows the user to scroll content within the current page. It is worth noting that most Android and iPhone browsers do not support this, although it has been added in iOS5. None of these browser support inertia scrolling for overflow:scroll, WP7 included.
The only way to get inertia scrolling for overflow content is to do it yourself using JavaScript. For WebKit browsers there is a popular library, iScroll, that provides this functionality. However, it does not work for WP7 (due to lack of CSS3 3D transforms that are used to push the scrolling content onto a different layer for hardware acceleration) - so you will need to write your own implementation. Good luck!
I'm developing a firefox addon and would like to have a fixed position (relative to the browser) semitransparent panel with 3 icons shown at the corner of every browser content area. These buttons will have to be able to communicate with a site that is not the site shown.
I know it would be possible to inject a fixed position div to html but I want the buttons to communicate with external site when pressed and also query information when they are loaded so I think that would violate same origin policy. This wouldn't work with image or other direct media urls either.
What would be the easiest way to create the floating icon panel?
After about of week of work I found it. Here is the answer, I hope this helps someone else:
http://marcada.ms/2010/02/getting-content-on-top-of-the-browser-space-using-xul/
The above adds the panel, transparency is not working (at least not in linux what I work with) because of the following bug. Sigh... opened in 2007 and not closed in 2012.
https://bugzilla.mozilla.org/show_bug.cgi?id=408284
edit2: I ended inserting html data to the body of the document using files from extension folder. Works very well including transparency.
edit3: If anyone is interested how this works in my plugin, check my live site at http://www.upmarker.com
We have a website that currently serves drawings to users via the SVG Viewer plugin. We have one client that sees it through IE8. With IE8, when they do a Change Zoom Level on the browser to anything other then 100%, the viewer tries to occupy the new space and zooms correctly. However, when the user tries to manipulate the frames inside that bound the viewer (it's a frameset website with the viewer being in the center) the entire site hangs. IE8 also shows that it takes up CPU cycles on the client computer, so it's trying to do something but hitting a loop.
I don't think this is actually our code and might just be something with SVG and how IE8 handles plugins and it's zoom. Does anyone know if this is a real problem and if there's a good solution?
If you are referring to the Adobe SVG Viewer plug-in, then I recommend that you (ideally) get your clients to start using a web browser that supports SVG natively — i.e. Chrome, Safari, Firefox, Opera; even IE9 (to some extent) — or use a different shim like SVGWeb to provide SVG support for those users of older browsers who also have Flash installed.
I found out what the problem was. I thought it was the SVG viewer trying to do something with the frames, when it turned out that I was just setting the frameset's initial size to the clientHeight and clientWidth, and then subtracting something from the height. That subtraction was a toolbar based in the frameset and, when you change the zoom level in the browser, there's a lock up that can occur with you trying to pull a components size and the client's size. At least, this is what I was seeing.