Surprisingly the SideBarPanel is not the full height of the container by default. I can't figure out how to make it 100% height. This is what it looks like currently.
Notice how its a little less than half the height of the sidebar container. Other panels don't have this issue. I've tried setting the html and body of the panel to 100% through CSS, and I've tried calling
sidebar.setHeight('100%');
both before and after sidebar.setPage. Instead of doing anything, it causes nothing to be displayed (probably because it doesn't support % height from this method). I don't know how to debug the JS or CSS of devtools extensions, so I am not sure how to figure out what is breaking. I know error's can be viewed from the Chrome Devtools Extension, but no error is thrown in this case.
As a bonus question, showing me how to debug devtools extensions would be nice. (Googling impossible since you just get normal debugging guides.)
In case anyone else comes across this when googling, this looks like it's currently fixed in Chrome canary: https://bugs.chromium.org/p/chromium/issues/detail?id=438126
Related
I've tried searching for this, and the closest related question that I could find was from 3+ years ago and had to do with the incognito window being dark, while a normal chrome window was light back then.
Now that we have the ability to have a light or dark mode browser, it's hard to find an icon design and color that looks good for both light and dark modes. Here's an example:
In the image above you can see that the first and third icons are black, so they are hard to see when using dark-mode. The middle icon (the one I'm using for my extension)looks great on dark mode, but terrible on light mode. See below:
So does anyone know if there is there a way to detect the browser mode (light or dark) and swap out the icon?
Thanks to wOxxOm I was able to figure this out.
First, I needed to create a content script (which I called toggleIcon.js) and add it to the manifist.json file.
Then I added the following to toggleIcon.js - which sends scheme: "dark" to my background.js file if window.matchMedia matches prefers-color-scheme: dark.
Then in my background.js file I listen for that message, and if request.scheme == "dark" I use chrome.broserAction.setIcon to change the paths for each of my icons to the dark version.
This effectively overrides my original icon paths as declared in the manifest.json file (as shown below).
The only downside I see is that this requires a content_script, which if you want your extension to work on any page, requires you to also add "matches": ["<all_urls>"] to your extension, which slows down the approval process. Which is why in my comments above I mentioned I had been avoiding using a content_script.
Also, I think it makes sense to use the version of your icons that work best on light-mode as your default, because I think the chrome extension page will pull from these for some of the icons they use (and that page has a white background). As an example, here's how my old icon looked (not enough contrast).
Hopefully this helps someone else!!
In a Chrome extension I want to change the viewport size, something like DevTools responsive view. I am looking into https://developer.chrome.com/extensions/tabs#type-ZoomSettingsMode and see methods for changing the zoom but not the actual width/height.
Dev Tools achieve this through debugger protocol.
You can try and emulate that, but you'll need to use chrome.debugger API.
The relevant command seems to be this: Emulation.setDeviceMetricsOverride - note that this is not part of the "stable" protocol and may change without warning.
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.
as I found out a few days ago when you click an extension button and popup shows up, its height is much higher than it needs to be if you need the height to be less than 350px. When something happens in the popup (animation e.g.) the height is adjusted properly according to the content. Setting height to html, body and general wrapper element didn't help. It might be some bug in the latest update of Chrome, I cannot test it in earlier builds, because of autoupdate.
I'll be thankful for any thoughts and advices.
Libor
UPDATE: I started to examine what can possibly cause this behaviour and found out this happens because of Twitter and Google Plus share buttons. They both modify DOM structure adding script tag which adds iframe. When commented, popup bubble appeared in correct size. The weird thing is facebook like button script does more or less the same, but it doesn't mess up the layout at all.
Like it was said here, the good solution to solve this problem is changing <html> to <!doctype html>
Same thing here with my extension and Chrome 19 on Windows 7. I must note that there were no problems with the previous version of Chrome. As you stated the issue shows up only on the first appearance of the popup - it shrinks correctly afterwards).
I'm using jQuery in my extension and I think I've partially solved it by adding
$("body").fadeOut(10).fadeIn(50);
though it doesn't always work (it probably will if you increment the fadeIn delay but!). Hope someone can provide a better solution to this.
EDIT. This should be guaranteed to always work (using your hint) although the user might see the resizing happening for a fraction of second:
$(window).load(function() {
$("body").fadeOut(10, function() { $(this).show(); });
});
Since long time i been having a real problem with the different ways that each browser display text.
Sure you have noticed that even when you create a stylesheet specifying everything about the font properties, still every browser display the same text with some differences, the usual problem is the font weight, that even if you specify it different browsers display it different ways.
I would like to know if some as come with a solution. Not turning the text into a image.
Thanks.
EDIT:
This is a example of the problem. On the left Firefox and right IE. However i have defined in the CSS font family, weight, size and still they render the fonts different.
Snapshot
Do you mean that on one browser its bold and another one its normal? A reset should fix that, but if it doesn't, it might be something overriding that.
If you're talking about fonts looking different, it is possible - for example, since Google Chrome / Chromium sandboxes the renderer process, the font rendering won't be affected by other parts of the system, and I believe that it uses some sort of special font rendering. To be honest, on my Linux install, I do get bolder fonts on Chromium, but Firefox displays them fine.
There's SIFR (as pointed above), but it needs Flash and it is a bit heavy. There's also Cufon http://cufon.shoqolate.com/ that uses Javascript. Could you show a screencast so we know what's the problem? Thanks.
SIFR is a good solution, as long as you're only trying to control the appearance of small chunks of text (headings, design elements, etc.)
Beyond that, browsers are perfectly allowed to render text any way they want, and getting it pixel-perfect between browsers and operating systems is usually not even desirable for larger chunks of text. Users will have different accessibility settings and anti-aliasing settings which are tuned to the way they want to read text, and in general websites should try to respect that.
You can use SIFR.
Although this problem is already about a week old, here is a solution that I found, that might be related:
http://blog.wolffmyren.com/2009/05/28/jquery-fadeinfadeout-ie-cleartype-glitch/
If you're not using jQuery, try removing the filter attribute from the elements that are displaying non-Cleartype'd text and it should work, according to that blog post.