Production server gets a lot (hundreds) of requests which ends with -moz-zoom-in.
It just adds -moz-zoom-in to current url, e.g. http://www.wikipaintings.org/en/paintings-by-genre/allegorical-painting/-moz-zoom-in
I made a search through project and did not find any mentions of this keyword. As I understand from documentation this is related to firefox cursor type.
I wasn't able to see such requests with firebug.
Any ideas what in CSS or HTML could cause such effect?
You should have a look at the user agent string of the requests. I suspect that it is some browser that doesn't support -moz-zoom-in (meaning: not Firefox, so it is not surprising that you cannot see that request in Firebug). You probably have cursor: -moz-zoom-in somewhere in your CSS styles, probably through some third-party library like jQuery UI, and that browser "fixes" it for you and turns it into cursor: url("-moz-zoom-in"). So it actually tries to load the cursor from that URL instead of ignoring the invalid cursor.
It is a CSS cursor which indicates that an element/object in a webpage is being resized. It is part of Mozilla extensions for CSS (they begin with -moz). For more information read this.
Related
I want to use the resource hint "prerender" (W3C) to speed up a website, but prerender is depricated in Chrome since v58. I read that NoState-Prefetch should be used instead (Google Dev), but I don't find anything on how to use it.
Does anybody know how I can prerender a site with the current version of Chrome or how to use "NoState-Prefetch"?
I'm grateful for every suggestion. Many thanks in advance.
Prerender is not deprecated, in fact it's part of the w3 standards. Though the standards are clear in that the user agent SHOULD fetch, however later it describes that it May preprocess, and adds a point later that the user agent might decide not to do anything.
Chrome initiated the prerender resource hint, previously it meant that the whole page should be pre-rendered in a hidden renderer process, but currently chrome does NoState-Prefetch which is less powerful than a full render but should still save time - in case the browser actually do it.
You can take a look at the following document to dig deeper, into why chrome changed the implementation of prerender, and when/what does No-State Prefetch do exactly.
To check that the browser did prerender locally:
go to chrome://net-export/ ( this will export a log of all the network activities happening from all chrome windows, apps, and extensions)
go to the website where you want to check prerendering, give it some time to idle and do the prerendering
save the json file from the net export page, and load it into https://netlog-viewer.appspot.com/
After its loaded, check the Prerender page found in the menu in the left side
I can see some images in my webpage that are not loading the reason is the wrong path inside the css or js file but how to know which js or css file is trying to load that resource. I tried too much in browser's inspector to find some way but I cannot figure out so I have to search each js and css file for the resource name. Is there any way to know the exact js or css file that is trying to load the failed resource.
Thanks
The Firefox and the Chrome DevTools provide a way to see what initiated the request of a resource within their Network panels.
Chrome DevTools
The Network panel within Chrome's DevTools provides information about the origin of a request within an Initiator column. All entries except the ones saying 'Other' link to the line within the JavaScript, CSS, or document, which caused the request.
For JavaScript calls it shows the stack trace that led to the request on hover.
It even allows you to highlight the initiators and dependencies by holding down Shift and hovering entries within the list.
Firefox DevTools
The Firefox DevTools Network Monitor has a Cause column indicating if a request came from JavaScript, the document, CSS, or some other source.
For JavaScript calls it provides the stack trace within a Stack Trace side bar when selecting the entry.
Unfortunately, for causes other than JavaScript it doesn't provide much useful information or links to the source files yet (as of Firefox 55). Therefore I've filed several enhancement requests to improve this feature.
I have a series of overlapping questions, the intersection of which can best be asked as:
Under what circumstances does an # character (an anchor) in a URL trigger an HTTP fetch, in the context of either an <a href or an <img src ?
Normally, should:
http://foo.com/bar.html#1
and
http://foo.com/bar.html#2
require two different HTTP fetches? I would think the answer should definitely be NO.
More specific details:
The situation that prompted this question was my first attempt to experiment with SVG stacking - a technique where multiple icons can be embedded within a single svg file, so that only a single HTTP request is necessary. Essentially, the idea is that you place multiple SVG icons within a single file, and use CSS to hide all of them, except the one that is selected using a CSS :target selector.
You can then select an individual icon using the # character in the URL when you write the img element in the HTML:
<img
src="stacked-icons.svg#icon3"
width="80"
height="60"
alt="SVG Stacked Image"
/>
When I try this out on Chrome it works perfectly. A single HTTP request is made, and multiple icons can be displayed via the same svg url, using different anchors/targets.
However, when I try this with Firefox (28), I see via the Console that multiple HTTP requests are made - one for each svg URL! So what I see is something like:
GET http://myhost.com/img/stacked-icons.svg#icon1
GET http://myhost.com/img/stacked-icons.svg#icon2
GET http://myhost.com/img/stacked-icons.svg#icon3
GET http://myhost.com/img/stacked-icons.svg#icon4
GET http://myhost.com/img/stacked-icons.svg#icon5
...which of course defeats the purpose of using SVG stacking in the first place.
Is there some reason Firefox is making a separate HTTP request for each URL instead of simply fetching img/stacked-icons.svg once like Chrome does?
This leads into the broader question of - what rules determine whether an # character in the URL should trigger an HTTP request?
Here's a demo in Plunker to help sort out some of these issues
Plunker
stack.svg#circ
stack.svg#rect
A URI has a couple basic components:
Protocol - determines how to send the request
Domain - where to send the request
Location - file path within the domain
Fragment - which part of the document to look in
Media Fragment URI
A fragment is simply identifying a portion of the entire file.
Depending on the implementation of the Media Fragment URI spec, it actually might be totally fair game for the browser to send along the Fragment Identifier. Think about a streaming video, some of which has been cached on the client. If the request is for /video.ogv#t=10,20 then the server can save space by only sending back the relevant portion/segment/fragment. Moreover, if the applicable portion of the media is already cached on the client, then the browser can prevent a round trip.
Think Round Trips, Not Requests
When a browser issues a GET Request, it does not necessarily mean that it needs to grab a fresh copy of the file all the way from the server. If it has already has a cached version, the request could be answered immediately.
HTTP Status Codes
200 - OK - Got the resource and returned from the server
302 - Found - Found the resource in the cache and not enough has changed since the previous request that we need to get a fresh copy.
Caching Disabled
Various things can affect whether or not a client will perform caching: The way the request was issued (F5 - soft refresh; Ctrl + R - hard refresh), the settings on the browser, any development tools that add attributes to requests, and the way the server handles those attributes. Often, when a browser's developer tools are open, it will automatically disable caching so you can easily test changes to files. If you're trying to observe caching behavior specifically, make sure you don't have any developer settings that are interfering with this.
When comparing requests across browsers, to help mitigate the differences between Developer Tool UI's, you should use a tool like fiddler to inspect the actual HTTP requests and responses that go out over the wire. I'll show you both for the simple plunker example. When the page loads it should request two different ids in the same stacked svg file.
Here are side by side requests of the same test page in Chrome 39, FF 34, and IE 11:
Caching Enabled
But we want to test what would happen on a normal client where caching is enabled. To do this, update your dev tools for each browser, or go to fiddler and Rules > Performance > and uncheck Disable Caching.
Now our request should look like this:
Now all the files are returned from the local cache, regardless of fragment ID
The developer tools for a particular browser might try to display the fragment id for your own benefit, but fiddler should always display the most accurate address that is actually requested. Every browser I tested omitted the fragment part of the address from the request:
Bundling Requests
Interestingly, chrome seems to be smart enough to prevent a second request for the same resource, but FF and IE fail to do so when a fragment is part of address. This is equally true for SVG's and PNG's. Consequently, the first time a page is ever requested, the browser will load one file for each time the SVG stack is actually used. Thereafter, it's happy to take the version from the cache, but will hurt performance for new viewers.
Final Score
CON: First Trip - SVG Stacks are not fully supported in all browsers. One request made per instance.
PRO: Second Trip - SVG resources will be cached appropriately
Additional Resources
simurai.com is widely thought to be the first application of using SVG stacks and the article explains some browser limitations that are currently in progress
Sven Hofmann has a great article about SVG Stacks that goes over some implementation models.
Here's the source code in Github if you'd like to fork it or play around with samples
Here's the official spec for Fragment Identifiers within SVG images
Quick look at Browser Support for SVG Fragments
Bugs
Typically, identical resources that are requested for a page will be bundled into a single request that will satisfy all requesting elements. Chrome appears to have already fixed this, but I've opened bugs for FF and IE to one day fix this.
Chrome - This very old bug which highlighted this issue appears to have been resolved for webkit.
Firefox - Bug Added Here
Internet Explorer - Bug Added Here
Every other website I visit, the inspector works as expected:
But in many of the sites I'm editing within apache server (using xampp) somehow they doesn't show the "filename.css:lineNumber" data
Also, every change I try to do in the inspector in thse sites, doesn't do anything to the code shown in the source tab.
I've tried refreshing, hard refreshing with cache, closing and opening the tab, closing and opening chrome again. The same problem occurs.
In other sites the inspector works well, but not in many of the localhost sites.
Has someone experienced this before? Is there a way to fix this?
If you are using a client-side CSS generator library such as Lea Verou's excellent -prefix-free or client-side Less, you will not see source information as it has all been processed and reinjected as style elements.
Client-side Less has a property [dumpLineNumbers] to include source line info as a comment in the generated source. (I'm not sure if this will display in Chrome's inspector - but I think it might)
The only "fix" I know of for -prefix-free is to temporarily remove it, obtain the source info for reference, then put it back in.
I have had the exact same problem (not using a css generator), and it appears to be a known bug with the current version of Chrome, the solution is to use the more up to date Beta version known as Chrome Canary - Here's the link :)
https://www.google.co.uk/intl/en/chrome/browser/canary.html
Try to check what the format of your CSS file is. I had the same trouble with the UNIX and Macintosh formats. For example, try to open you CSS file in Notepad++ and in the bottom right corner of the window you'll see your current format. If you see UNIX or Macintosh there, click it with the right button of your mouse and change to DOS/Windows. Then save your file and refresh your page in Chrome. It definitely helped in my case.enter image description here
I have a weird problem. I generate a HTML page, hosted let's say at http://www.x.com/stuff which contains
<head>
<link type="application/atom+xml" rel="alternate" href="/stuff/feed"/>
..
</head>
The result is:
In IE7 all works well - you can click on the feed icon in the browser and the feed is displayed
In Firefox, view source, click on the linked /stuff/feed and you see the source of the feed, so that works as expected
In Firefox, view the page (not source), then click on the feed icon in the address bar, I get an error that it can't retrieve the URL feed://http//www.x.com/stuff/feed
So the problem is, that it's appending feed:// to the front of the URL and then taking out the colon : after the http. I understand that feed: is HTTP anyway so perhaps the adding of that isn't a big problem.
But anyway, the fact is, that URL Firefox generates out of my <link> tag doesn't work.
I have considered making the URL absolute, but I haven't found any evidence that those URLs have to be absolute, nor can I understand why that would be the case. And for various reasons it would be inconvenient in my code to generate an absolute URL. I can do it if necessary but I would prefer to see proof (e.g. specification, or Mozilla bug report) that it's necessary before making my code messy
What do you think? Does anyone know of any evidence that the URL should be absolute? Or am I doing something else wrong? It seems such a simple/obvious tag, where nothing could go wrong, but I can't get it to work.
I had the same problem. IT was caused by the proxy server at work that my web traffic was going through. Firefox changed "http://server.tld/feed-url" to "feed://http//server.tld/feed-url". Since the web proxy that all my http traffic is going through does not recognize the "feed://" protocol, it rejects my request as invalid.
The only workaround I have found so far is to manually configure the proxy settings in Firefox. Right now you probably have them automatically configured by your system. If you know your proxy information, you can instead manually configure it. Doing so only for http/https/ftp allowed me to access the feed because Firefox then handled the feed:// URL directly (which ended up with it redirecting to http:// like I wanted).
To configure your proxy settings directly, you'll need to go to Edit -> Preferences -> Advanced -> Settings (next to "Connection"). Use manual settings. You'll have to determine the proxy settings that your system is already using.
Note that the missing colon (mentioned by Piet) is not a bug on your site. It's a conversion that the Firefox subscribe is doing. Also note that it is not a problem caused by a relative URL as Julien suggests. Firefox is converting it to an absolute URL, but then removing the colon in the http:// protocol prefix so that it can be appended to "feed://" (changing the protocol and supplying the original absolute URL as the "URL" for the new "feed" protocol).
Can you provide a link to your site or the specific HTML-page to see this live? Because the ATOM-feed of this question on SO is announced exactly the way you try to link your ATOM-feed:
<link rel="alternate" type="application/atom+xml" title="Feed for question 'Link to RSS/Atom feed, relative, doesn't work in Firefox'" href="/feeds/question/4438794">
This works fine with my Firefox/3.6.13.
The fact that the non-working base URL contains a typo is suspicious: that would happen if something is overriding it by accident.
Does your page contain a bad base element? The base element (and RFC 1808) is not supported exactly the same across all browsers, so if you have something like this in your document (note the missing :):
<base href="http//www.x.com/">
then it might be used inconsistently by browsers to resolve relative references, depending on element placement, rendering mode, error fallback behavior, or other factors.
If the document contains no base element, check that you aren't accidentally introducing an incorrect base URL through some other means, such as the Content-Location HTTP header.
This is a bug in Firefox or FoxyProxy or something.
Not only do I see exactly the same problem for stackoverflow (go to a question in Firefox, click on the feed icon, see the same weird feed://http//... URL) but also on http://news.google.com/
I have written to a friend at a completely unrelated company, he sees the same error from his FireFox on those standard internet pages.
It doesn't help to use absolute URLs in the <link> tag; news.google.com uses absolute URLs, for example.
It turns out, if you go to the proxy settings in Firefox, if you select "Use System Proxy Settings" this happens; if you enter proxy details manually or use no proxy, this problem doesn't occur.
This seems to be this bug here http://foxyproxy.mozdev.org/drupal/content/problem-with-feed-and-proxy
Put an absolute URL, it's a good practice for elements and won't break browsers...