I am experiencing an issue with production build version of the Sencha Touch based application not being able to apply styles properly in IE10 and Chrome.
Steps to reproduce:
Main.js
Ext.define('Lab.view.Main', {
extend: 'Ext.Panel',
xtype: 'main',
requires: [
],
config: {
tabBarPosition: 'bottom',
items: [
{
xtype: 'panel',
cls: 'MyFirstLogo',
itemId: 'firstLogo'
} ]
}
});
SCSS file - app.scss
.MyFirstLogo{
height: auto !important;
min-height: 100px;
min-width: 404px;
padding: 0px;
background-image:url(../../resources/images/test1.jpeg);
background-repeat:no-repeat;
background-position: left;
}
Make sure the background image URL is like this in resources/sass/app.scss - ../../resources/images/test1.jpeg.
Run "sencha app build production" in project root (Lab/)
Access the application in IE10 64bit (Win 7) : http://localhost/lab/build/production/Lab/
Images are not shown at all in IE10. However, when trying this in Chrome it works well. Chrome somehow is able to convert the ../../resources/images/test1.jpeg to http://localhost/lab/build/production/Lab/resources/images/test1.jpeg but IE10 doesn't do it and fails to show the image. This way it also works in my local development environment as it goes with my project structure.
In order to make it work in IE10, I have changed the image URL from ../../resources/images/test1.jpeg to resources/images/test1.jpeg (This actually makes sense as resources/ directory is in the project root) in resources/sass/app.scss and rebuild it for production. In this case image starts to appear in IE10 but now when I use Chrome - Image does't show up and Chrome is trying to retrieve the image from this URL which in not right: http://localhost/lab/build/production/Lab/resources/css/resources/images/test1.jpeg, and it fails. This way it DOES NOT also work in my local development environment.
This issue happens for other resources as well like "fonts".
Could you please help me understand what's going on here with Sencha's Production Build version not working in both IE10 and Chrome at the same time? Is this this bug with Sencha Touch or Chrome or I am missing something here?
It turns out to be the known bug in Sencha Touch as confirmed by the Sencha people. Check this link: http://www.sencha.com/forum/showthread.php?266275. Thanks #peter and #arthurakay for you help. If I need a workaround or further discussion on this. I will start the discussion again. Thanks guys!
Why are you going back so many directories in the relative file path?
Whether you're in development or production, the CSS file lives at:
{app_root}/resources/css/app.css
Assuming your images are here:
{app_root}/resources/images/
...then your filepaths should look like this:
background-image:url(../images/test1.jpeg);
FYI I'm assuming Touch 2.3 and Cmd 4.0.x since you didn't specify.
The address you access the application (in any browser) becomes the page base address. In your case it's http://localhost/lab/build/production/Lab/
You can confirm this by printing alert(document.location.href).
Check the trailing slash, please.
Address ../../resources/images/test1.jpeg then means http://localhost/lab/build/production/Lab/../../resources/images/test1.jpeg and translates to incorrect
http://localhost/lab/build/resources/images/test1.jpeg
Modify the relative address to ../resources/images/test1.jpeg to get
http://localhost/lab/build/production/resources/css/resources/images/test1.jpeg
You can always verify the resulting address by entering it to the browser's address bar.
Both IE and Chrome translate paths correctly as this is their basic task.
I have found a workaround to make images/icons visible on both IE10 and Chrome.
Here, CSS property given for any given class containing "background-image" should contain working URL's for both IE10 and Chrome as follows :
.menuHome {
background:url(resources/icons/menu/Home.png),url(../icons/menu/Home.png) no-repeat center;
}
Here both URL's are present in the CSS property. So IE10 will fetch image from 1st URL and Chrome will fetch image from 2nd url.
Related
Steps to reproduce
I have application bootstrapped from vue-cli with a webpack template. I'm running it on Chrome 65.0.3325.146 but it also exists on 64.X.XXX version.
I'm adding here:
package.json: https://gist.github.com/marcinlesek/a7e6076ce4befe2e810743fdbaf81480
webpack.base.conf.js: https://gist.github.com/marcinlesek/80cbf27b6ef4172248709f32c257d0cd
What is expected?
The application should works fine with Chrome Browser and I should be able to disable/change styles in Chrome Dev Tools.
What is actually happening?
When I change style via Chrome dev tools it broke all styles (after changing or disabling one property) that page looks like in pure HTML without any line of style code. Fresh dev tools setup and Chrome reinstall doesn't help. What is a bit tricky, on Firefox 58.0.2 everything works correctly.
My collegues also had this problem, so it convince me that it isn't my local bug but something bigger on Vue side. Also find some questions regarding this bug, like Page styles break when I change styles in Chrome DevTools with Webpack HMR
Thanks in advance.
Best regards,
Marcin
I find another solution. Thanks to answer of #munstrocity regarding changing cheap-module-eval-source-map to eval-source-map. Unfortunately, this change didn't fix for me my styles in Chrome Dev Tools but give me good point to check.
After a bit I found, that changing cacheBusting: true, to false in config/index.js help to solve that and now it's possible to change style in Chrome Dev Tools.
// file: config/index.js
...
// If you have problems debugging vue-files in devtools,
// set this to false - it *may* help
// https://vue-loader.vuejs.org/en/options.html#cachebusting
cacheBusting: false,
...
Hope this will help anyone! :)
I've encountered the issue as well, and I was able to prevent this by disabling CSS Source maps in development. I'm still looking into why this only happens on Chrome, but at least we can start looking there. I don't believe this is a Webpack issue.
-- Updated --
I simply changed the devtool to "eval-source-map" in my config/index.js file and everything works.
file: config/index.js
...
// https://webpack.js.org/configuration/devtool/#development
devtool: 'eval-source-map'
...
I had this issue, but only when I had multiple blocks in one component.
E.g.,
<style scoped>
...
</style>
<style>
...
</style>
I couldn't work out the exact cause, except I noted that I could see that the sources devtools tab only ever shows one inline style block, so figure there's some fragile trickery there. My quick workaround was to simply move at least one of the style blocks into its own file.
<style scoped>
...
</style>
<style src="./my-component.unscoped.css"></style>
I don't know why this worked. Hope it helps someone.
Inside your webpack config file you can try to enable source map for your sass loader configuration.
You need to edit your file as follow:
module.exports = {
css: {
loaderOptions: {
sass: {
sourceMap: true
}
}
}
}
I am using Rails pdfkit gem to render multi-page pdf files. The rendered pdf file picks up the CSS(SCSS) styling and page breaks as expected. However, when I try to render the same pdf document in production, it seems like the styling only loads some CSS rules and ignores others such as parent container's width and height declarations. Here is my CSS (SCSS) for the parent container element:
.policy_pdf{
font-family: Arial, sans-serif;
.pdf-page{
width:98%;
height:17.1in;
margin:auto;
page-break-after:always;
...
#media screen{
border: 1px dotted red;
}
page-break-after:always;
}
...
}
and PDFKit initializer:
PDFKit.configure do |config|
config.default_options = {
:page_size => 'Legal',
}
end
Here is an example of a pdf rendered in development:
and here is how this same pdf looks in production:
The red line around the doc is a CSS rule I introduced to display how page edges are rendered in production.
Environments
Both, development and production (Digital Ocean Droplet) are using the same version of Ubutnu (16.04).
What have you tried?
At first I thought that some of the CSS classes I am using for pdf-kit such as .page get overwritten by some conflicting rules at compilation, so I tried using unique class names such as .pdf-page instead of .page.
I then tried to see whether it can be related to SCSS compilation. But nested border and background-color declarations within the same stylesheet are getting 'picked-up' and rendered fine. The policy-pdf block inside the compiled application.css looks correct as well.
Disabling smart-shrinking made the PDF look even more "crumbled".
Applying size / width CSS rules (in-line and via external stylesheet) to the html tag as suggested in this post:
Clue:
Both, production and development are running the same version of wkhtmltopdf of (~> 0.12.2). However, running wkhtmltopdf -V, returns wkhtmltopdf 0.12.2.1(with patched qt)
I had similar porblem. In my case it was missing fonts on Ubuntu.
sudo apt-get install ttf-mscorefonts-installer
sudo fc-cache
https://askubuntu.com/questions/651441/how-to-install-arial-font-in-ubuntu
I had such problem a while back too.
I'm not sure, but if I recall correctly, it ended up being different versions of ghost-script.
You can check the version by running gs -v
The production output appears to have larger margins than the dev output.
From your given sample of the relevant css showing your "page config", this might be simply fixed by specifying those margins. This isn't done on the virtual page element .pdf-page, but inside the #page selector.
#page {
margin:10mm 15mm 10mm 15mm;
}
Depending on how this design has being developed and previewed, (print dialog, dev tools media emulation) you may need to adjust those margins to conform to the margins used to preview the work.
This can be done within the Chrome print dialog by setting Destination to 'Save as PDF', expanding 'More settings', selecting 'Customised' within Margins and finally entering the values or directly dragging the margins that now appear over the print preview.
While I'm not familiar with PDFKit, I've developed templates for AthenaPDF, I assume they're all pretty much standard PDF converters using Headless Chrome under the hood. We found it was easier and more flexible to define the #page properties through css rather than attempt to configure it through the AthenaPDF docker service. It only took standard, minimal and none as margin values.
I'm using Firefox 48.0 on Ubuntu 14.
My profile directory is ~/.mozilla/firefox/v2fcrlqx.default
I've put a file in there called userContent.css with a simple test rule in it:
body { background-color: red; }
But I'm not getting any results.
I also tried creating a folder called Chrome beneath my profile directory and copying userContent.css into that, but that doesn't work either.
Has Firefox dropped support for user stylesheets or I am doing something wrong?
User styles are now disabled by default in Firefox.
To activate them:
Type about:config?filter=toolkit.legacyUserProfileCustomizations.stylesheets in the address bar. Set the option to true.
Restart Firefox.
hope it will help.
I've fixed it. The user stylesheet has to go into a directory called chrome (not Chrome) below the profile directory.
I'm new at Drupal and I'm now administrating an existing site. There's a bug that the home slider asigns a size of 0x0 to its images, so only the pager is displayed.
When you open the website in another browser, it works fine.
What could be the problem? I googled it but non of the solutions I found work.
Thanks,
Brian
First, it's not Drupal related issue, but it's CSS related, so you tagged it wrong and probably googled about it wrong.
Problem can be in:
a) your theme (called "Porto")
b) slideshow module if you are using one
In any case you should (temporary) disable caching of CSS on page (admin menu) Configuration -> Development -> Performace
URL:
/admin/config/development/performance
Then find out what CSS causes this issue, find out what file you should change (user Firebug or some similar tool), change the CSS file, turn on CSS cache again, clear the cache (just in case).
So, Darko's solution can be correct, but definitely there is no point of changing cached CSS file since it will be re-generated in time and you'll loose your change, but it should be applied on correct file. Instead, as I said, disable cache, find the real CSS file, change it there and clear the cache.
Or, since you have access to all CSS files you don't even have to disable the cache, but just find and fix CSS in real file and clear the cache.
Let's say it is CSS related problem but it is not quite correct answer here.
You can see in different browsers different render outputs based on module settings. Issue is on this setting:
element.style {
height: 460px;
position: relative;
width: 930px;
}
element.style values are the values you set up in your module (in this case view_slideshow). In Firefox you get good output (code from above) but in google chrome you got just next code:
element.style {
position: relative;
}
It is a bug for sure and it is a module related because for some reason Google Chrome not read values which are set in module. First you should try to update your slideshow module on latest release. If you still have a problem you can easily fix it via changing CSS file.
#MilanG have a good point because once you clear the cache new CSS will be generated and you will have the same problem. I will try to explain what you should with little more details.
Go on admin/config/development/performance (if you are using drupal 7) and check out option Aggregate and compress CSS files. That will disable caching of CSS.
Open Firebug on your front page and find next line:
<div id="views_slideshow_cycle_teaser_section_carrusel_home- block"class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section" style="position: relative;">
If you use Firebug on Firefox you should find same line (but it is outputted different as you can see):
<div id="views_slideshow_cycle_teaser_section_carrusel_home-block" class="views-slideshow-cycle-main-frame views_slideshow_cycle_teaser_section" style="position: relative; width: 930px; height: 460px;">
Now you find which CSS is used on that line (it should be something like sites/all/themes/your_theme_name/css/views.css )
Find the right line in that CSS and change it like i showed you in my first post.
Clear the cache and now you go back on admin/config/development/performance and turn on caching.
Hope this helps.
You can fix this like this:
Go on sites/default/files/css
Open css_Ad8ea4Il0r-gy2oHf2eZpgamt3p0W3GurWCoZa6MhXU.css
Find this code in CSS:
#views_slideshow_cycle_teaser_section_carrusel_home-block{display:inline-block;}
Replace it with this code:
#views_slideshow_cycle_teaser_section_carrusel_home-block{display:inline-block;height:460px;width:930px;}
Save CSS
Long story short I have an application running in a production environment that contains all of my stylesheets. I am now faced with using these stylesheets on another separate server. This all works fine without any issues in every browser except ie8 (ie9 even works). The external stylesheet appears to be working until it calls a resource using a relative path.
For example the following does not appear in ie8:
#header-region #menu .navbar-nav > li > a {
background: #5f9bbc url("../img/diag_pat_trans.png") repeat;
}
The only reason I can think that this would be happening is if every other browser is looking at the stylesheet and when it runs into a relative path it is using the fqdn from which the script was obtained and traversing from its root by whatever realtive path, then when we get to ie8 it is simply obtaining the script code and throwing it in the browser, then when it hits any realtive paths it freaks/ignores!?!?
Curious if anyone else has ran into this issue? Yes the ideal thing would be not to support IE8, but I'm in a position where that is not possible. Any further insight into this would be greatly appreciated :)
I was on the right path with the issue having something to do with cross-domain interaction and IE8. Upon further digging I ran across this post where the user was using a respond-proxy.html page to load respond.js, which resolved this issue.