After changing one of the data sources for a Mapbox component, I get these styleimagemissing console warnings alerting that some icons for points of interest are not available. For my purposes it's OK that those icons aren't shown, so I'm wondering if there's a way to avoid getting these warnings from the frontend code, without changing the data sources. Perhaps ignoring points of interest or images/icons?
I've already tried writing some function that's triggered when an image is missing instead of the warning:
map.on('styleimagemissing', () => {
// do something
});
But this seems to happen after the warning has already been triggered.
As a workaround, you could simply load a transparent icon for every icon that is in the style (assuming you can determine such a list).
Related
"#material-ui/core": "4.12.3"
"#storybook/addon-storyshots": "6.3.12",
"#storybook/react": "6.3.12",
"react": "17.0.2",
Cannot use Dialog in a Storybook Storyshots test without errors, because the workarounds to get ReactDOM.createPortal and react-test-renderer to work together, causes the Material UI Dialog to throw console warnings in the tests.
I can workaround the first issue by either using the disablePortal property within Dialog stories or by mocking it out like this in testSetup:
jest.mock("react-dom", () => ({
...jest.requireActual("react-dom"),
createPortal: (children: ReactNode) => children,
}));
Both these workarounds create a second issue, which is for every story that contains a Dialog we get a console warning creating a huge amount of noise in the test output.
"Warning: Material-UI: the modal content node does not accept focus. For the benefit of assistive technologies, the tabIndex of the node is being set to "-1"."
I have checked for duplicates and have several related issues like this one, however, it's not the same as the actual Dialogs and Storybooks work fine with no errors and are composed properly with an internal focusable DialogContent. This issue is only affecting the storyshot tests when the portal is mocked or bypassed.
If I add the disableAutoFocus property to each Dialog within the Storybooks, the console warnings go away, however it seems like a hack.
Does anyone know why these warnings are appearing or a better way to resolve this?
Thanks
I am trying to adjust the UI in my game to properly fit on the screen of an iPhone X.
In my code I am attempting to code the line return Screen.safeArea
However 'safeArea' is highlighted red and when I hover over the error with my cursor a message is displayed saying "error CS0117: 'UnityEngine.Screen' does not contain a definition for 'safeArea'".
I dont understand why I'm getting this error because according to Unity's documentation UnityEngine.Screen does contain a definition for safeArea.
Any inclination or idea as to why I am running into this error?
Also, I am working with Unity 2017.2.0f3
As per comments bellow, code as been asked for.
private Screen ReturnSafeArea(){return Screen.safeArea}
as I tried saying, the code has nothing to do with it. Even in this simplistic instance of the use of Screen.safeArea, safeArea is listed as not a definition of UnityEngine.Screen.
Hovering over safeArea displays the following message
"'Screen' does not contain a definition for 'safeArea"
Screen.screenArea is of type Rect and your method is defined as returning a value of type Screen
https://docs.unity3d.com/ScriptReference/Screen-safeArea.html
One way to correct this:
private Rect ReturnSafeArea(){
return Screen.safeArea;
}
Additionally, the field was added in 2017.2.0p1 (Nov 6) and you're on 2017.2.0f3 (Oct 3). Link is for 0.2, but 0.f3 does not have its own page, so likely was made either the same day or very shortly after.
I believe Screen.safeArea was added in a minor release of 2017.2, so 2017.2.0f3 would not have it. Try your code in 2017.2.1 and newer to confirm. It's too bad the documentation doesn't specify that.
I have a problem with g-leaflet - it shows as a grey rectangle only (with a bit of the map at top left) until I resize the window (manually). Then it shows up. Sometimes parts of maps show when I hover over an area but this too is incomplete and problematic. Here:
The code that I use to add the G-Leaflet map to my GXT VerticalContainer (com.sencha.gxt.widget.core.client.container.VerticalLayoutContainer) is as follows, taken from G-Leaflet example:
LeafletDrawResourceInjector.ensureInjected();
final MapWidget mapWidget = new MapWidget();
mapWidget.setSize("1000px", "750px"); // I added this myself to try to fix the issue
myVerticalLayout.add(mapWidget);
(I also set the size of the "myVerticalLayout" container).
Please help!
Leaflet is really finicky. Scheduling a defferred call to invalidateSize() was not enough. Had to make my own JavaScript call to its invalidateSize using setTimeout, also making sure that all the containers are attached before this happens. Only hen it would show.
Firefox addon. I'm porting an existing addon to a restartless one. I have a panel with a lot of UI elements (mostly boxes/description and images) in it, and it is very convenient for me to define the panel elements in an XUL overlay file. I will have lots of bloated js code if I don't.
The panel element (parent) itself is created in code dynamically, and then I use loadOverlay, wait for the 'merged' event and then append the panel element's children from the overlayed document. I also make sure that the elements are cleaned up upon a remove.
However, using overlays will most probably won't pass an AMO review. And some of the reasons I think are :
In most cases overlay elements will cause problems while removing (eg: toolbar buttons remembering their positions etc.)
There are problems with attaching js/css files in an overlay file.
loadOverlay is buggy (496320, 330458)
And here are my inferences :
loadOverlay() API itself is not deprecated - in fact it is 'not frozen and may change later' - which means possibly it will be use-able in future.
The bug that a second overlay load fails, is not applicable in my case, as I don't initialize without an overlay merge.
Using static overlay for preference windows etc. is perfectly acceptable as of now.
The panel in my case behaves a lot like a preference window (which is brought up on demand and cleaned up upon addon removal)
I don't have any js/css attached to the overlay, nor any event listeners for the elements. The overlay is only used to define boxes and description text - nothing more.
So considering these, is it acceptable to use overlays and loadOverlay() for a restartless addon ? If not, is there an alternative ?
About overlays, by checking source code of restartless addon that extend existing addon (like ehh), I see the overlay.xul is auto merged with the existing addon's. So it shouldn't be a problem to use overlay.
What is the proper way to use the SDK to make a dialog (which is not anchored to the add-on bar, etc. but shows centered on screen)? It doesn't seem like there is any API for this important capability. I do see windows/utils has open but I have two problems with that:
The dialog opening seems to require "chrome" privs to get it to be centered on the screen (and I'd be expectant of add-on reviewers complaining of chrome privs, and even if not, I'd like to try to stick to the SDK way).
While I can get the DOM window reference of the new window/utils' open() dialog, I'm not sure how to attach a content script so I can respond to user interaction in a way that prompts (and can respond to) privileged behavior ala postMessage or port.emit (without again, directly working with chrome privs).
Ok, this answer should have been pretty obvious for anyone with a little experience with the SDK. I realized I can just use a panel. In my defense, the name "panel" is not as clear as "dialog" in conjuring up this idea, and I am so used to using panels with widgets, that it hadn't occurred to me that I could use it independently!
Edit
Unfortunately, as per Bug 595040, these dialogs are not persistent, meaning if the panel loses focus, the "dialog" is gone... So panel looks like it is not a suitable candidate after all... :(
Edit 2
I've since moved on and have gotten things working mostly to my satisfaction with sdk/window/utils and openDialog on whose returned window I add a load listener and then call tabs.activeTab.on('ready', and then set tabs.activeTab.url to my add-on local HTML file so the ready event will get a tab to which I can attach a worker. There is still the problem with chrome privs I suppose, but at least the main communications are using SDK processes.
Update to Edit 2:
Code sample provided by request:
var data = require('sdk/self').data,
tabs = require('sdk/tabs');
var win = require('sdk/window/utils').openDialog({
// No "url" supplied here in this case as we add it below (in order to have a ready listener in place before load which can give us access to the tab worker)
// For more, see https://developer.mozilla.org/en-US/docs/Web/API/window.open#Position_and_size_features
features: Object.keys({
chrome: true, // Needed for centerscreen per docs
centerscreen: true, // Doesn't seem to be working for some reason (even though it does work when calling via XPCOM)
resizable: true,
scrollbars: true
}).join() + ',width=850,height=650',
name: "My window name"
// parent:
// args:
});
win.addEventListener('load', function () {
tabs.activeTab.on('ready', function (tab) {
var worker = tab.attach({
contentScriptFile: ....
// ...
});
// Use worker.port.on, worker.port.emit, etc...
});
tabs.activeTab.url = data.url('myHTMLFile.html');
});
if the panel loses focus, the "dialog" is gone...
It doesn't get destroyed, just hides, right? If so, depending on why it's getting hidden, you can just call show() on it again.
You'd want to make sure it's not being hidden for a good reason before calling show again. If there's a specific situation in which it's losing focus where you don't want it to, create a listener for that situation, then call if (!panel.isShown) panel.show();
For example, if it's losing focus because a user clicks outside the box, then that's probably the expected behaviour and nothing should be done. If it's losing focus when the browser/tab loses focus, just register a tab.on('activate', aboveFunction)
Simply adding ",screenX=0,screenY=0" (or any values, the zeroes seem to be meaningless) to the features screen seems to fix centerscreen.