Difficult to explain (issue title may not be clear enough), so here are the use cases:
1) Create a context, and then visit the site in a different browser (or private browser window). The context will not apply since that browser doesn't initially have the cookie. You have to resize or refresh to get the correctly loaded context.
2) Create two blocks and two contexts. One context will have max-width: 1199px and show block 1, and the other context will have min-width: 1200px and show block 2. Visit the site with your browser maximized, and you'll see block 2. Open a new tab, shrink your window to well under 1200px, and go to your site...and you will still see block 2. This is because it assumes the stored cookie is applicable, but in this case it's not because the stored cookie doesn't match the new condition of your window being smaller.
I'm attaching a patch as a quick fix. However, this would be better implemented as inline JS in the header so that it would reload the page rather than rendering everything first.
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | context_breakpoint-check_existing_cookie.patch | 2.63 KB | sethfisher |
Comments
Comment #1
sethfisher commentedThe patch.
Comment #2
theduke commentedSorry it took me a while.
Patch is applied.
Comment #3
dadderley commentedHi guys I have just started using this.
This module would be very useful to me if I could get it to work.
I have this dev release installed:
Last packaged version: 7.x-1.0-alpha5+1-dev
Last updated: December 22, 2012 - 04:46
I have 3 contexts on the go (using 3 Omega breakpoints)
I have these breakpoints in my theme settings:
I am using this to add/remove blocks for different sizes.
Of the 3 contexts I have, only the one using breakpoints[wide] works.
For the other contexts (when resizing) the page reloads the way that it should. It looks like it is trying tries to load the block, then gives up.
Comment #4
dadderley commentedI have been doing more testing.
I am using the same set of breakpoints and they seem to be working as the page re-loads when it hits each breakpoint.
I have a breakpoint condition set up for each of the sizes (mobile, narrow, normal and wide).
Each of these adds a bock to the same region.
Here is what I am seeing:
@mobile width
(specific mobile block) shows.
Then stays in place for all widths (does not go away)
@narrow width
(specific narrow block) never shows
(specific mobile block) remains
@normal width
(specific normal block) never shows
(specific mobile block) remains
@wide width
(specific wide block) shows as it should. Is removed when browser window is sized down. If they all behaved like this one life would be good.
(specific mobile block) remains
So, not sure what is going on.
It almost feels like the breakpoints are not right.
I grabbed them from here http://drupal.org/node/1706600#comment-6295816 and put them in my theme info file.
They get imported without error. I am using an Omega subtheme.
Can you confirm that these breakpoints are correct?
Also, I think what I am experiencing is part of this specific issue "Current context is not checked against existing cookie when page is loaded" so I did not create a new issue. If this is a bad assumption, I could create an new issue.
Comment #5
dadderley commentedSorry for clouding the issue.
My problem has nothing to do with this issue and everything to do with my breakpoint module configuration.
Context Breakpoint appears to be doing its job.
For my purpose, these settings from http://drupal.org/node/1706600#comment-6295816, do not work.
If any body has a workable set of breakpoints that work for Omega, please post. There seems to be a lack of documentation and examples.
Comment #6
dadderley commentedOK,
It seems that the Breakpoint modelled on Omega media queries are too complex for Context Breakpoint
http://drupal.org/node/1706600#comment-6930600
So back to square one for me in trying to put together all of the pieces to find a workable solution.
I guess, I should start a new issue as none of this has any relevance to this specific issue.
Comment #7
dadderley commentedSorry for all the confusion.
Comment #8
gurrmag commentedIn relation to the patch in #1, is there any news on the suggestion that:
Having to reload the page is really slowing performance when visiting my site for the first time from a mobile.
Happy to help with testing if I can...
Comment #9
theduke commentedSorry for the delay.
The cookie is now checked immediately in the header.
No more waiting for attach() to be triggered.
It is already committed.
I will release a new version tonight.