I found out that Chrome extension popups have a maximum height of 600px and maximum width of 800px.
My requirement is to make the popup height equal to screen height.
I can see there isn't a simple way to do it but I stumbled upon the Bloomberg extension (https://chrome.google.com/webstore/detail/bloomberg/llgiblikeclfoebojkplbcmnicgcabhg). This somehow fixes the popup height to exactly what I want.
I am new to extension development. How does this Bloomberd extension manage to resize popup to full-screen.
As you found, 600px height and 800px width - are the maximums for a popup size. (see ref in sources)
According mentioned Bloomberg case – it is implemented via injecting code in the current tab using content-scripts.
Related
I've added a PNG animation (acting like a animated GIF) to an iBook HTML widget using CSS, JavaScript and HTML.
The problem is that there is a maximize button when hovering over the widget in the iBook preview. I want to remove this because it is only supposed to be an animation that plays when entering the page, and I don't want the user to be able to interact with it.
How can I remove this functionality from the widget?
Setting the widget width and height in your info.plist file the same as the width and height in iBooks author prevents opening in full screen when tapping on it.
I don't know if this logic works on Mac or iPhone, but it seems to work on the iPad.
Currently, I check if the window manager supports _NET_WM_STATE_FULLSCREEN. If it does then I use XGetWindowProperty to get array of atom's of _NET_WM_STATE. If it is the atom of _NET_WM_STATE_FULLSCREEN is found then i know it is fullscreen.
However on many windows, like the Desktop WM_NAME window, it doesn't have this atom. In fact doing doing _NET_WM_STATE fetch wit XGetWindowProperty fails, this i think is because the _NET_WM_STATE is removed when the window doesn't have focus? THe docs say its removed when window is unmapped.
I did test Desktops width and height using XGetWindowRect and I compared it to the screen width and height by using macros of WidthOfScreen and HeightOfScreen and desktop does match full screen width and height. What's up with the atom missing? Any sure fire way to detect full screen?
Thanks
I have a 1900px-wide web page at https://zackel.com/50/a0.html that I'd like to display as intelligently as I can on smaller screens, say 1024 x 768. If you show the page now on a 1024-wide screen the left side is cut off and there's no scroll bar to go over and see it.
I've been using
http://www.infobyip.com/testwebsiteresolution.php?url=https%3A%2F%2Fzackel.com%2F50%2Fa0.html&width=1024&height=768&in_browser=true
to view the page on various screens.
How can I get browsers to scroll over to the left to see the Box 1 and Box 2 content there?
Or what do I have to do to the HTML/CSS to get it to adjust on load to a smaller screen?
Thanks
You need a responsive/fluid width design , also if by chance you are using firefox , you can change the resolution of your browser window by pressing CTRL+SHIFT+M
Couple of responsive HTML5 frameworks that might be of help to you --
http://foundation.zurb.com/
http://getbootstrap.com/
I have a dojo text area which I'm binding it to a field. I saw that on browser, its height is OK but if I open the xpage in the Notes client its height is twice bigger. I tried adding height property for the text area, but it doesn't work.
Thanks in advance!
Browsers Firefox and XPiNC (XPages in Notes Client - that is XULrunner based on Firefox) show Dojo Text Area (dijit.form.Textarea) always with at least two rows even it contains only one line of text.
Other browsers like Chrome and IE work like expected.
You don't have a chance to change that behavior with style "height"/"minHeight" or parameter "rows".
The only solution I found is to create an own Textarea widget. But I am not sure if it's worth it...
This issue shows up only for contents with one line. As soon as you have two or more text lines Dojo Text Area's height adapts exactly - for all browsers.
Try setting the height using css styles, that should do it.
Update:
In case css should not be working here try using the classic HTML attributes 'cols' and 'rows'. I don't have Domino Designer ata hand right now, so I can't tell whether those attributes are available. If not you could add them yourself using the 'attrs' group.
I have a view withing a panel with this styleCLass applied.
.scrollPanel { width:100%; height: 375px; overflow: auto;}
That panel is nested with an extension pages Application control.
I want both the height and the width of the panel set so the scroll bars of the panel appear and the browsers scroll bars are NOT activated.
This CSS works perfectly for width. I can resize my browser window and the width of the panel adjusts as needed and the browser horizontal scroll bars never come on.
But if I try 100% for height, it does not work the same. If I resize for height then the vertical scroll bars for the browser appear.
Also it would be nice to have the height of the panel always equal to the height of the available screen. With 100%, the height is very small if the view is collapsed. The height expands when the view expands. I would like for it always to be the same size percentage wise to the available height of the browser.
P.S. The set size I have of 375 works perfectly with the exception it does not resize with the browser.
Is there any way to do this?
You would need to register a window.onresize event that fetches the actual size of the window and modifies the panel accordingly, e.g. by setting its height with a style.
So the best way would be to create a method that modifies the size of your panel according to the windows size, respecting a minimum and a maximum value. Once that function is finished, you would just need to register it to the onresize event that gets fired when anything has changed the viewports display dimensions (read, a real resize or something that has enabled the windows scrollbars).
In the perfect world you would debounce/throttle the execution of this method to maybe at most every 100ms to avoid excessive CPU load during a window resize with the mouse and a window border, because depending on the browser, that event gets fired on every single pixel the mouse has moved during such a resize - which is fairly often and may lead to a slower UI response.