I use Selenium Webdriver, I want clear cookies before execute test. I use code from official 'Selenium` site. This is code:
Cookie cookie = new Cookie("key", "value");
driver.manage().addCookie(cookie);
Set<Cookie> allCookies = driver.manage().getCookies();
for (Cookie loadedCookie : allCookies) {
System.out.println(String.format("%s -> %s", loadedCookie.getName(), loadedCookie.getValue()));
}
driver.manage().deleteAllCookies();
But I get notification: - Cookie cannot be resolved to a type, Set cannot be resolved to a type
The Set is of java.util package.
The Cookie is of org.openqa.selenium package.
You need to import those two classes to make your code work:
import java.util.Set;
import org.openqa.selenium.Cookie;
To make the suffering less painful, every modern Java IDE has an automatic function for this:
In Eclipse, it's called "Organize imports" and sits under Ctrl+Shift+O.
In IntelliJ, it's called "Optimize imports" and sits under Ctrl+Alt+O.
In NetBeans, it's also called somehow and sits under Ctrl+Shift+I.
I'd check your imports. I suspect that you are using the javax cookie when you need the selenium one.
javax.servlet.http.Cookie
org.openqa.selenium.Cookie
Related
i can't find a tutorial how to use package vuei18n-po in vue main.ts.
Yts documentation is small, and not well descriped.
https://www.npmjs.com/package/vuei18n-po.
I have never use something like this inside app initiation in vue, so it is realy hard.
it is my code:
import { createApp } from "vue";
import App from "./App.vue";
import router from "./router";
import "jquery";
import "bootstrap";
import "bootstrap/dist/css/bootstrap.min.css";
import vuei18nPo from "vuei18n-po";
const app = createApp(App);
await vuei18nPo({
po: ["django.po", "../../backend/locale/pl/LC_MESSAGES/django.po"],
messagesFile: "generated/allInOne.json",
messagesDir: "generated",
});
app.use(router);
app.mount("#app");
In my code i did not use plug it in option, because i wanted to generate it first.
EDIT
I found this error on localhost
Module "fs" has been externalized for browser compatibility. Cannot
access "fs.realpath" in client code.
I dont understand what this mean too.
I don't think that this package is meant to be used for client side code regarding the error especially because po is a GUI-based solution.
The vuei18n-po is meant to transform some files locally with some JS backend like a Node.js app (this is the Usage part in package's README).
Then for the 2nd part (Plug it in), you could use the generated files with an i18n setup for VueJS with the regular Vue2 package for i18n: https://kazupon.github.io/vue-i18n/
Or the one for Vue3: https://vue-i18n.intlify.dev/
If it's not clear enough, feel free to read articles on how to setup i18n with Vue.
This is then a 2 step problem. I recommend that you start with a simple example of 2 small JSON files in Vue, then that you try to convert your .po files with the vuei18n-po package.
In my app, I'm storing state in a global object (similar to, but not Redux). When users navigate around the site, I want this state to persist. Gatsby intelligently tries to prefetch page content for links it finds on the page, but sometimes when navigating to a particular route, the page is fetched from the server, the window reloads, and I lose my state.
A little more context: I'm already using the Gatsby Link component for every link in the app, and if needing to change routes programmatically, I'm using the Gatsby navigate function. I've tried storing state in location.state, but this is also wiped if the page is not prefetched.
Is there any way to force Gatsby to prefetch routes so I don't lose my app state?
UPDATE:
Adding code snippet from my gatsby-ssr.js in case that might be related:
// gatsby-ssr.js
import React from "react";
import wrapWithState from "#state/wrapWithState"; <-- this is a React context provider
import { SearchConfig } from "#modules/search/index";
import { DefaultLayout, HeaderWrap, Lang } from "#layout";
export const wrapRootElement = wrapWithState;
export const wrapPageElement = ({ element, props }) => {
const { location } = props;
return (
<>
<Lang currentPath={location.href} />
<SearchConfig />
<HeaderWrap currentPath={location.href} />
<DefaultLayout {...props}>{element}</DefaultLayout>
</>
);
};
It's simple really. If a link is not generated using Link component it will behave just like a regular anchor and the browser will perform a page load (resetting your state). First identify which links act like regular links and see why Link component is not used there.
I am creating an application using Ionic2 with angular2 and Typescript2. the main idea of the application is to detect the user location.
and due to the need to make sure that this data is correct we need to make sure that users don't fake their locations.
after a lot of search I found the following answer Detect or avoid mock GPS location but this answer can't help me a lot because this plugin uses javascript not typescript and i am facing a problem in using it
So, Is it possible to check or preventing a user from faking their GPS location?
Typescript IS JavaScript.
You have three options to operate the plugin and let typescript compile
Declare it as a known javascript var
declare var plugins;
plugins.fakeLocation.check(function(IsEnabledMockLocations){
console.log(IsEnabledMockLocations);
});
Writing a custom typing for it
declare namespace plugins {
export namespace fakeLocation {
export function check(callback: Function): void;
}
}
Use any casting
(<any>window).plugins.fakeLocation.check(function(IsEnabledMockLocations){
console.log(IsEnabledMockLocations);
});
I am testing a Flask application (Flask 0.9), and in particular I have a session fixture that I would like to run in the documented-way, being something like this (as I understand it):
from flask import Flask, session
app = Flask(__name__)
#app.route('/', methods=['POST'])
def m():
logging.error(session) # expect {'x': 1}
return ""
with app.test_request_context() as trc:
with app.test_client() as c:
with c.session_transaction() as sess:
sess['x'] = 1
c.post()
This works as expected, with the output being something like this:
ERROR:root:<SecureCookieSession {'x': 1}>
Unfortunately I am encountering an unexpected result where the session data is not set in the endpoint function, i.e. the output is something like this:
ERROR:root:<SecureCookieSession {}>
This issue exhibits only when run from my unit testing framework. As it stands, I am unable to reproduce this problem with a degenerate case, though I have made a fairly substantial effort with a gist of some of this effort here. The salient points being that I have included itsdangerous and Google App Engine testbed, expecting maybe one of them to have been the cause.
On my own system I have gone further than the gist, and almost completely replicated my unit test framework trying to isolate this. Likewise, I have removed ever-increasing amounts of relevant code from my testing framework. To the point, I am unable to think of differences between the degenerate case and my stripped-down framework that could influence the outcome. I have traversed the c.post() call in pdb to try eek out the cause of this malignity, but have yet to glean any useful insight.
Which is all to say, I would be grateful for a little direction or suggestion as to where the issue may lie. What could possibly be influencing the Werkzeug context in such a way that the session_transaction is not being honoured?
In my case, I was restricting cookies to a specific domain automatically by loading a configuration file. By updating the configuration on-the-fly, I was able to get cookies to work while unit testing. Setting the SESSION_COOKIE_DOMAIN property to None, all domains (namely localhost) were able to set sessions.
app.config.update(
SESSION_COOKIE_DOMAIN = None
)
You may want to fiddle around with the configuration settings described under Configuration Handling in the docs.
I hate to resurrect an old question, but I believe that I figured out the solution to this issue. For testing, try setting your server name to localhost:
app.config['SERVER_NAME'] = 'localhost'
I was originally using Brian's hack, but this solved the problem for me.
Without a testcase that actually fails it's hard to say much anything. All I can think of is that the TestClient instance you're using the make the request is different from the one you use to set up the session. E.g. you could make the gist fail as expected with this:
with self.app.test_client() as c:
with c.session_transaction() as sess:
sess['d'] = 1
self.client.post()
But as this isn't the case here or the gist, go figure.
Here is what I ended up doing:
# Code that modifies the current `session`; we must be in a test context already.
headers = {}
with self.client.session_transaction():
# Get the cookie that is sent to the browser to establish a connection
# via a fake request.
response = make_response()
self.app.session_interface.save_session(self.app, session, response)
headers['Cookie'] = response.headers.get('Set-Cookie', '')
self.client.post(..., headers=headers) # also works for .get, .put, etc.
Here's the fiddle. Here's the gist with the contents of my local file.
As you can see, the HTML and JavaScript are identical, and I'm loading identical versions of the jQuery, Handlebars.js, and Ember.js libraries. It works as expected locally, but does not render the application template on jsFiddle.net.
I see the following error in the Web Console:
[19:44:18.202] Error: assertion failed: You must pass at least an object and event name to Ember.addListener # https://github.com/downloads/emberjs/ember.js/ember-latest.js:51
BTW-To test the gist as a local HTML file, make sure to run it behind a web server or your browser won't download the JavaScript libs. If you have thin installed (ruby webserver), go to the directory it's in and run thin -A file start, then navigate to localhost:3000/jsfiddle-problem.html in your browser.
If you set the "Code Wrap" configuration on your fiddle to one of the options other than "onLoad" your application will work. Here is an example.
The reason for this is Ember initializes an application when the jQuery ready event fires (assuming you have not set Ember.Application.autoinit to false). With the jsFiddle "Code Wrap" configuration set to "onLoad" your application is introduced to the document after the jQuery ready event has fired, and consequently after Ember auto-initializes.
See the snippet below from ember-latest, taken on the day of this writing, which documents Ember auto-initialization being performed in a handler function passed to $().ready.
if (this.autoinit) {
var self = this;
this.$().ready(function() {
if (self.isDestroyed || self.isInitialized) return;
self.initialize();
});
}
This was strange - I couldn't get your fiddle working, specifically your {{controller.foo}} call until I disabled autoinit. I am guessing when using jsfiddle the application initialize kicks off before seeing your router. I also noticed with your fiddle the router was not logging any output even when you had enableLogging set to true.
I updated your fiddle to not use autoinit, http://jsfiddle.net/zS5uu/4/. I know a new version of ember-latest was released today, I wonder if anything about initialization changed.