I think it's because Chrome scales the borders for the upgrades in a strange manner and at certain zoom levels instead of the borders being 4 pixels they'll be 3.5 pixels or something similar.

1. Open the Inspect menu (right click and press Inspect)
2. Find Application in the top bar of the menu (you may need the drop-down accessible by pressing the two right-facing arrows)
3. On the left selection menu drop down Local Storage.
4. Right click on clickercookie.github.io and press Clear
5. Refresh your page

If you need additional help or don't understand these instruction please comment below.

Press the reset button.
Try importing data.
Repeat again because sometimes it doesn't trigger.
Doesn't import data.

When a save has a building unlocked that isn't unlocked by default, when you import data where that building hasn't been unlocked yet, it will show the original save's status on that building's visibility, which is the wrong visibility. It should make any buildings that are not unlocked in the imported save disappear.

Wasn't originally a big issue, but now with more upgrades being added the constraint of a certain box's size is becoming a chore, the solution here is to make the box bigger again or to figure out a way to shorten the price down from "6,000,000" to "6 million". It's more likely I'll just make the box bigger because I don't want to figure out shortening it like that until way later down the line.

Going through the building's CSS for the mobile version, I noticed a lot of really strange and fixed behavior that doesn't work the way that I would expect it to. I think that most of this probably comes from the fact that back when buildings were first made I wasn't aware of flexboxes, so I made them without it. I feel like rebuilding the HTML design layout of the buildings to use flexboxes could probably massively improve them.

Welp, here we are. I said I wouldn't do it, but when it comes to saving it seems I will never be satisfied.

• So why am I doing this?
  The main issue I have with the 0.6 saving system is that it relies heavily on the usage of eval(). At the time, my logic behind this was that since Clicker Cookie is a static site, there was no harm in this situation to using it. Then I thought about it way more than I should've and now I don't like it. It's a s*** system that uses obscure methods to find the names and values of both variables and object properties, and anyone who didn't write it (you) cannot understand it without looking super closely. It even took ChatGPT about 5 tries to figure out what I was asking it to write. The system I've been brainstorming for the past few weeks is, to be honest, more primitive than the old version when you first look at it, but it's actually very similar to the way Cookie Clicker saves, and really for me that's excuse enough.

• So how does it work?
  The new saving system stores its data in JSON formatting, but is more organized than the last system. It looks like this:

{
	"header": {
		"version":"0.6"
		"versionBranch":"main",
		"format":"4"
	},
	"data": [
		data in old formatting
	]
}

Now for the data section. Data is going to be stored in an array of values, each index will be a different variable value. A great example of this is the very early version of the saving system from 0.5, except for this time instead of basing it on newlines it will be stored as an array.

• Won't that make main.js one line bigger for each variable?
  Yes, it will make the file substantially bigger, but 0.7 is going to be a massive overhaul to the way ALL code is handled, and with it will come breaking main.js up into multiple files to find what you're looking for much easier. So to answer the question, there won't be a long main.js file, there will probably be a long saving.js file.
• When is it coming?
  This is a big change for being so late in the 0.6 development cycle, and to get 0.6 out in a timely manner, I plan to release this system in either 0.6.2 or 0.7. It's going to require another annoying conversion process, but 0.6 is already months off schedule, and having another thing to worry about on top of adding 0.6's content to the mobile version isn't going to help anyone.

Ultimately, for me, this was a necessary change, and even though I know it will take an extremely long time to implement, I feel its addition is integral for Clicker Cookie to have an actual easy-to-work-with codebase, which right now it certainly does not.

Primarily this has to do with the popup-text class and how every element inside a popup requires it. I think it would be a much simpler system if this could be omitted. There are other issues with Advanced Popups that need to be addressed, but popup-text is the biggest one.

We already have the savingAllowed variable (which should be renamed to autoSavingAllowed) so all that needs to be done is adding a new toggle under Miscellaneous in settings.

All known bugs are listed below:

Planned

• Resetting save and importing data does not import data.

Can't/won't be fixed

• Cookie image is draggable on certain browsers
• Acting as if you were to highlight the entire page will make it so every element is draggable like its an image.
• Resizing window breaks most elements

Instead of the very array-oriented version of our current upgrade system, this new one aims to be more easily extensible and more simple to understand.

Now, upgrades will be stored as an array of objects, with each object containing the data for its upgrade. Below is an example of the implementation.

// the description of almost every upgrade is the same, but just in case we want to add more upgrades in the future
// a "desc" field has been added to the upgrades array. Most upgrade will just reference a string in this array
// that correlates to the upgrade it's associated with, though.
upgrades.defaultUpgradeDescriptions = [
    `Multiplys Keyboard and clicking ${personalization.currentClicked.toLowerCase()} production by 2`,
    "Multiplys Grandpa production by 2"
    // so on, so forth
]

upgrades.data = [
    { // the "id" would be 0 because that's the index in the array
        name: "Reinforced Keys",
        quote: "press harder",
        price: 100,
        img: "reinforced-keys.png",
        desc: defaultUpgradeDescriptions[0],
        building: keyboard, // not sure exactly how buffing the building will work, maybe passing the instance into this will work?
        unlocked: false,
        bought: false
    }
]

Like so:

const currentClickedItems = [
    {
        name: "cookie",
        pluralName: "cookies",
        img: "cookie.png", // if we want to do it automagically (`${name}.png`) then we can, but there's no harm in using this. maybe it can be optional?
        circular: true, // border-radius should be 128px
        pixelated: false // image-rendering auto/pixelated
    }
]

On Chrome using DevTools to emulate a mobile device, this issue does not occur, so it may take a while to find it's source.

This is hopefully self-explanatory.

It is easiest to see when in the Info menu because of the changelogs.

Currently, if the size of the screen changes on the mobile version, the footer doesn't compensate for it and will stay in the same spot it was with the old screen size. It doesn't affect the end user because it's not very common for them to, you know, add an inch to their phone's screen, but I want to make it better anyway :D

Currently, saves.loadAutoSave() and saves.importReadData() contain much of the same function. This creates unnecessary garbage when working on how saves are loaded, and should be addressed by making a saves.loadSave() function as opposed to this system.

Currently, the floating-box style building box looks fine visually, but the issue becomes that the buildings can't scale easily horizontally, making integration of the scrollbar a difficult task.

Instead, making the building's boxes look more like they do in the mobile version (connected) would make the boxes change width much easier.

Back when Clicker Cookie was first made I sucked at web development and didn't know that inline event handlers were bad practice, so they should be changed to use .addEventListener() as such is the standard for the web.

In personal testing this is completely finished, but still is most likely going to be released in 0.7 to more closely align with that update's goals.

Advanced popups are great, but there's a lot you can't do with them. One thing that annoys me about them is that you can't add padding to the popup without doing a bunch of gymnastics with JS. Another thing that I recently thought would be a beneficial addition would be to be able to change the level of filter that appears when the popup is present (idk if this is actually possible or not). Then there's also the filter parameter that was removed, but for a time I've been planning on re-implementing it. With this many ideas for how to configure the functionality of an advanced popup, we'll very quickly start stacking massive amounts of parameters on the helper.popup.createAdvanced() function. To fix this, I propose that we have only one parameter, options, that will be an object containing various configuration options for the popup. Here is an example of the interface for this object:

interface AdvancedPopupOptions {
    showFilter: boolean;
    filterLevel: number;
    innerPadding: number;
}