1072186 - Freeze layout objects after they're loaded

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::Keyboard, defect)

Description

[John Lu [:mnjul][Please NI or I'll miss]]

As we expect layout objects and key objects to be immutable after they're loaded/normalized in LayoutLoader, it's better we guard them with Object.freeze(), such that future attempts to mutate them will fail.

Comment 1

[John Lu [:mnjul][Please NI or I'll miss]]

Working on this while I'm waiting for other patch's feedback. Will probably take bug 1074613 and bug 1042191 in this bug too.

Comment 2

[John Lu [:mnjul][Please NI or I'll miss]]

(In reply to John Lu [:mnjul] [MoCoTPE] from comment #1)
> Working on this while I'm waiting for other patch's feedback. Will probably
> take bug 1074613 and bug 1042191 in this bug too.

s/1042191/1072191

Comment 3

[John Lu [:mnjul][Please NI or I'll miss]]

Attachment: Patch (PR @ GitHub)

Comment 4

[John Lu [:mnjul][Please NI or I'll miss]]

Comment on attachment 8503957 [details] [review]
Patch (PR @ GitHub)

Hi Tim,

Please see if the patch is good for this bug and bug 1072191 and bug 1074613.

A tricky part is that we can't really freeze spaceKey and enterKey during normalization because layoutManager may change it. So they're frozen in layoutManager after the appropriate modification was done.

p.s. you can't change the property value of an object with some frozen prototype where the property is defined, i.e.

o = {'abc': 123};
o2 = Object.create(Object.freeze(o));
o2.abc = 456;

and |o2.abc| will remain |123| .

Comment 5

[John Lu [:mnjul][Please NI or I'll miss]]

Comment on attachment 8503957 [details] [review]
Patch (PR @ GitHub)

So, Tim and I discussed and we have not come to a clear policy on what and how we should (deep-)freeze and what and how we should (deep-)copy.

Thus I'll leave this bug for now. The patch for the other two bugs is now on bug 1072191.

Comment 6

[BMO Automation]

Firefox OS is not being worked on