I want to avoid wasting time on social media websites. I block them on my windows pc by adding them to the "hosts" file. I can still access the sites via wifi from my mobile (lumia). So I also block them in my router. That only works for http but not https url's.
Is there a way to block selected sites on the phone browser, or the phone itself? Maybe there is an app for that?
Related
Problem:
Web page with sms: and mailto: links fail on ios mobile safari browser. A click on the link redirects you to:
Safari cannot open the page because it cannot redirect to locations
starting with "sms:"
or
Safari cannot open the page because it cannot redirect to locations
starting with "mailto:"
These used to work just fine up until around two or three months ago. Now these fail on Apple mobile devices using the Safari browser.
Background:
I create responsive web pages for activity based teams. One of the things we do is provide a team roster. The roster includes links for telephone numbers, SMS text pages and Email.
To keep things simple, we are using simple web pages.
Because of security and privacy concerns, this content is only served via ajax call via node.js server after login. We're using a single node.js Express server to host the website content and manage http/api calls.
Generally a click on the link pushes the mobile device into the appropriate native app for a phone call, SMS text message or email.
This has been working great for a couple of years, on all devices.
Lately we're seeing the problem on iPhones... but...
Here's the really weird part. I've got three teams using this technique.. The failure is only on TWO of the three teams. SMS link works just fine there.
The "tel:" link works fine on all devices.
The failures only occur on two of the three sites for sms: and mailto: on the iphone. Things still work just fine on Android devices, on Windows and on MacOS. The problem is Apple mobile devices.
The two sites that have the failures are Progressive Web Apps, with a manifest.json file and service_worker.js. The site that works fine has neither of those. When I remove the manifest, and turn off the service worker there is no improvement.
All three sites hosted via App engine at Google Cloud. The two sites that fail are only using web_app.appspot.com addressing. The site that functions well is using a real URL, pointing to the app engine location.
Typical Code:
<li>
<div class="userName">Jane Doe</div>
<div class="phoneNumber">321-555-1234</div>
<div class="sms"><img src="../images/crosstxt-icon.jpg"></div>
<div class="email"><img src="../images/email-icon.png"></div>
</li>
I wonder if this will show the issue, if you open this up in the browser of your Apple mobile device:
Click here to create a SMS message.
<br>
Click here to create an email message.
Apparently that's a fail. You don't even get to see the run snippet button on my mobile device.
Testing, more testing...
I just figured out... if I save the site to my mobile device homepage, such that an icon is added to home screen and in display mode, you can NOT see the top URL address bar, nor the Safari options bar on the bottom then the SMS: will fail. If you just open the address in Safari, but don't save the file, then it will work great.
Again, when I'm in Apple Web Application mode, the SMS link fails.
One hack... open the site via Safari mobile browser on the iphone. Save the site to Home Page. Verify the Icon is on the mobile phone. Go to Settings --> Safari --> Advanced --> Website Data, then Delete the site by sliding the content left. Cache storage is clean, but the Icon remains on the mobile screen. Use the Icon to aid in login, but don't save the site again. Note the URL line is visible. SMS will work.
Still testing here...
I tried to build a simple example to show the issue. I was totally unable to get the sample to fail with the error messages above. For reference the test site is here. The test source code is here.
I'm suspecting that the issue revolves around the fact that the two sites in question are both located at a subdomain site. (mywebapp.appspot.com) When the manifest includes all "valid" content the site does appear as a ios Apple Web app without visible URL line... but whenever I'm in that mode, SMS links are a total fail.
With that said, you can control the storage mode via <meta name="apple-mobile-web-app-capable" content="yes"> .
During my testing, I also noticed that whenever the manifest.json file contains // comment marks anywhere the file is ignored by Safari. Normally // comments are not allowed in a .json file, but according the MSN source, they are fine in a manifest.json file.
The choice is
a bit ugly and functional, or
pretty and non-functional
Currently I'm running <meta name="apple-mobile-web-app-capable" content="no">... I get the advantage of a custom icon on the home screen, even though the web app is still obviously inside a mobile browser with top/bottom info lines visible, sigh.
I'm creating a website with multiple different pages (accessible through the nav bar). When I zoom in on one of these pages (using ctrl +/-), the other pages don't necessarily adopt that zoom level. So, for instance, if I make the "home" page 125% and then click onto the "contact" page, the "contact" page won't automatically be 125% as well.
How do I get all pages of my website to adopt whatever browser zoom level the user has chosen?
I believe different browsers work differently when opening local files (using the file:// protocol).
I assume that since the browser believes it's opening 2 different HTML files which may not have any connection it will just set the zoom-level to the default one. Some browsers may remember this setting for all files opened in the future.
When you are on the same domain however using a website or local web server (google it, read up on xampp or Node.js to simulate a real website) which uses the http:// protocol the browser probably saves the zoom-level per domain (youtube.com, google.com etc.) so that it knows to set the zoom on all pages under that domain.
I want to set up dynamic html serving on my apache server. It means that for different types of devices (mobile, tablet, desktop) content should be different, while url stays the same.
For example:
From desktop www.example.com/index.html
Completely different layout
From mobile device www.example.com/index.html
Completely different layout
How to achieve this? What would be apache configuration?
I don't want to use RWD because layout between devices differs too much.
I'm not familiar enough with Apache to say this definitively but I don't think you can actually serve different webpages on the same url without some sort of server side page generation (such as a web application framework).
However, if you have a normal site on www.example.com and a mobile-friendly site on m.example.com you can configure Apache to redirect users of a mobile device to your mobile site.
Google "Apache detect mobile device" and you see links such as http://blog.justin.kelly.org.au/apache-mobile-device-detection/ which seems to do pretty much exactly that.
One warning is in order: the detection is based on the user agent string and is therefore comprised of fuzzy logic; some user agents (some devices) might not be detected correctly. I would therefore advise you to also have a link at the top of your 'normal' webpage to users can click to get to your 'mobile' webpage.
My app is completely html CSS and JavaScript. I am running into a little problem because I would like the user to be able to use my webpage from the browser or use the app and maintain the cookies between the two.
Is this possible?
No, this is not possible because the WebBrowser control used in your hybrid app does not share anything with the Internet Explorer. They are completely separated and each one is sandboxed.
This also prevents other applications from reusing such cookies.
I'm making an offline webpage that automatically logs into an online website.
The website uses ssl (https) and to login it uses a form (post variables)
The problem I'm encountering is the following:
The site only accepts my offline form, when I open the online login page first.
This is because the website uses (server-side) sessions which are made when opening the first page. (The purpose of the session is to detect a time-out)
When I first open the online website and then run my offline page everything works fine.
So I need to make my offline webpage open the online website before posting the form automatically.
I tryed this with an iframe, but this doesn't work in internet explorer, as it is a https website. (It does work in Chrome, firefox,...)
I was wondering if Ajax could send a https page request before posting my form. But I guess not as it is https.
Does anybody know a method to send a https page request just like the browser does, but without showing it's output? Afterward I can automatically submit my form.
Thanks in advance!
Internet Explorer treats iframes from other domains as third party content, and uses a separate set of security policies for them. The security zone settings are also in effect between file:/// "local machine"/"offline" webpages and "internet"/"online" webpages. Cookies are usually blocked from third party content (depending on your settings), which means that the unique session key set in the cookies won't be saved. Without this key, the site you are trying to log in to will "forget" your session/login.
Cross-domain AJAX request are also affected by security zones and cross-domain policies, but the settings may differ between IE versions.
There are ways around the limitations, using P3P policies, if you control the target web page. Cookie blocked/not saved in IFRAME in Internet Explorer shows how. But, if you do own the web page, it would be better to enable or implement your own "remember me" feature.
In your case, depending on if you are the only one to use your offline autologin webpage, perhaps allowing third party cookies in Internet Explorer will help. See Options > Privacy > Allow all cookies (or in a similar). This will allow others (mostly ad companies) to track you all over the internet though.
If the purpose for your autologin page is testing, rather than actually using the browser as a human being, perhaps you can automate both logging in and testing?